Billing device and processing method

ABSTRACT

A billing device and processing method is disclosed. In one embodiment, the method includes i) collecting a billing log according to performing a biz template at the business logic processing unit, ii) verifying validity of the collected billing log, iii) performing a standardizing process on the verified billing log, iv) generating billing data by applying a predetermined billing policy according to the standardized billing log, v) generating a billing file (MDR) to transmit to a billing legacy system of a mobile communication system using the generated billing data and vi) transmitting the generated billing file (MDR) to the billing legacy system.

RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patentapplication Ser. No. 12/538,037 (filed in the U.S. Patent and TrademarkOffice on Aug. 7, 2009), which is a divisional of U.S. patentapplication Ser. No. 12/114,690, filed May 2, 2008, now issued as U.S.Pat. No. 8,230,040, which is a continuation application, and claims thebenefit under 35 U.S.C. §§120 and 365 of PCT Application No.PCT/KR2006/004524, filed on Nov. 2, 2006 and, which is herebyincorporated by reference. PCT/KR2006/004524 also claimed priority fromKorean Patent Applications Nos. 10-2005-0107242 (filed on Nov. 9, 2005),10-2005-0109047 (filed on Nov. 15, 2005), 10-2005-0109308 (filed on Nov.15, 2005), 10-2005-0109586 (filed on Nov. 16, 2005), 10-2005-0111368(filed on Nov. 21, 2005), 10-2005-0111369 (filed on Nov. 21, 2005),10-2005-0111373 (filed on Nov. 21, 2005), 10-2006-0103170 (filed on Oct.23, 2006), 10-2005-0105076 (filed on Nov. 3, 2005), 10-2005-0107184(filed on Nov. 9, 2005), 10-2005-0107243 (filed on Nov. 9, 2005),10-2005-0107244 (filed on Nov. 9, 2005), 10-2005-0107245 (filed on Nov.9, 2005), 10-2005-0107246 (filed on Nov. 9, 2005), 10-2005-0107247(filed on Nov. 9, 2005), 10-2005-0107248 (filed on Nov. 9, 2005),10-2005-0107249 (filed on Nov. 9, 2005), 10-2005-0108611 (filed on Nov.14, 2005), 10-2005-0108638 (filed on Nov. 14, 2005), and 10-2005-0108643(filed on Nov. 14, 2005), all of which are hereby incorporated byreference.

This application relates to 1) U.S. patent application Ser. No.12/537,931 filed on Aug. 7, 2009, now issued as U.S. Pat. No. 8,229,998,entitled “OPEN INTERFACE DEVICE AND METHOD” (Attorney docket: 804.0001),2) U.S. patent application Ser. No. 12/537,940 filed on Aug. 7, 2009,now issued as U.S. Pat. No. 8,073,932, entitled “BUSINESS LOGIC DEVICEAND PROCESSING METHOD” (Attorney docket: EZINT4.023C1DV2), and 3) U.S.patent application Ser. No. 12/538,052 filed on Aug. 7, 2009, now issuedas U.S. Pat. No. 8,463,841, entitled “LEGACY COOPERATION DEVICE ANDPROCESSING METHOD” (Attorney docket: 804.0002), all of which areconcurrently filed with this application and incorporated herein byreference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to an open type mobile business supportingsystem and method for supporting various business models from contentproviders or service providers (CP/SP) by providing an integratedinterface for various resources of a mobile communication system.

2. Description of the Related Technology

With the development of wireless Internet technology and thepopularization of mobile communication terminals, various mobilebusiness models have been introduced to provide services to a user of amobile communication terminal through a wireless communication system. Awireless Internet based content service provider often uses a service ofa wireless communication system to authenticate a user or to perform abilling operation for a predetermined service to a corresponding user.

SUMMARY OF CERTAIN INVENTIVE ASPECTS

One aspect of the invention is an open mobile business supporting methodand system for effectively supporting various business models desired bya content/service provider by providing a single interface that canintegrally use various resources of a mobile communication system.

Another aspect of the invention is an open mobile business supportingmethod for supporting a content provider/service provider (CP/SP) mobileservice using a legacy system of a mobile communication system. The openmobile business supporting method in accordance with an embodiment ofthe present invention can include: setting up low-level functions, whichcan be grouped as a unit function among service logics of a CP/SP andperformed by a wireless communication system, as biz logics; receiving arequest of performing a predetermined biz logic from the CP/SP; andperforming the request biz logic by cooperating with a legacy system ofa mobile communication system and internally performing predeterminedprocesses, and returning the result of performing the biz logic to theCP/SP.

Another aspect of the invention is an open mobile business supportingsystem. The pen mobile business supporting system in accordance with anembodiment of the present invention can include: a business logicprocessing unit for storing, managing, and performing a biz templatethat groups service logics of a content provider/service provider(CP/SP) to a unit function, defined based on a biz logic which is alow-level function performed by a mobile communication system, andformed by arranging a plurality of biz objects in a predetermined order,where the biz object cooperates with each legacy system of a mobilecommunication system and performs a comparison and determinationoperation on the result of cooperating; an open interface processingunit for receiving a request of performing a predetermined biz logicfrom a CP/SP, requesting the business logic processing unit to perform abiz template corresponding to the requested biz logic, receiving theresult of the request, and transferring the received result to theCP/SP; and a legacy cooperation processing unit for relaying a requestfrom a predetermined legacy system and returning the result to thepredetermine legacy system while performing a biz template by relayinginterworking between the business logic processing unit and a legacysystem of a mobile communication system.

According to certain embodiments of the present invention, an openmobile business supporting system supports various infra resources in awireless communication system to be independently operated andintegrally driven, thereby making the various infra resourcesconveniently and effectively cooperated together. Furthermore, the openmobile business supporting system provides an integrated interface forthe infra resources in the wireless communication system. Therefore, aservice and an application layer can easily use the infra resources ofthe wireless communication system.

Moreover, the open mobile business supporting system according to atleast one embodiment of the present invention classifies biz logicmanagement, service management, and service execution, therebyeffectively supporting various business models.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating a network for a mobile service.

FIG. 2 is a diagram illustrating a mobile communication system.

FIG. 3 is a flowchart illustrating an open mobile business supportingmethod according to an embodiment of the present invention.

FIG. 4 to FIG. 10 are diagrams illustrating a method of embodying a bizlogic and a biz template by an open mobile business supporting methodaccording to an embodiment of the present invention.

FIG. 11 and FIG. 12 show a biz template embodied by a method ofembodying a biz logic and a biz template by an open mobile businesssupporting method according to an embodiment of the present invention.

FIG. 13 is a block diagram illustrating an open mobile businesssupporting system according to an embodiment of the present invention.

FIG. 14A and FIG. 14B are flowcharts illustrating an open mobilebusiness supporting method according to an embodiment of the presentinvention.

FIG. 15 is a block diagram illustrating an open mobile businesssupporting system according to an embodiment of the present invention.

FIG. 16 is a diagram illustrating message flow in an open mobilebusiness supporting system according to an embodiment of the presentinvention.

FIG. 17 is a flowchart illustrating an operation of an open mobilebusiness supporting system according to an embodiment of the presentinvention.

FIG. 18 is a block diagram illustrating the OI processing unit accordingto an embodiment according to an embodiment of the present invention.

FIG. 19 is a flowchart illustrating a detailed operation of the OIprocessing unit in the open mobile business supporting system accordingto an embodiment of the present invention.

FIG. 20 is a block diagram illustrating a business logic processingunit.

FIG. 21 is a flowchart illustrating a business logic processing methodin the open mobile business supporting system according to an embodimentof the present invention.

FIG. 22 to FIG. 25 are flowcharts illustrating a method of performing abiz template according to an embodiment of the present invention.

FIG. 26 is a block diagram illustrating a billing processing unit and anetwork structure according to an embodiment of the present invention.

FIG. 27 is a block diagram illustrating a billing processing unit in theopen mobile business supporting system according to an embodiment of thepresent invention.

FIG. 28 is a block diagram illustrating a billing policy unit of thebilling processing unit according to an embodiment of the presentinvention.

FIG. 29 is a flowchart illustrating a method of billing processaccording to an embodiment of the present invention.

FIG. 30 is a flowchart illustrating a procedure of applying the billingpolicy according to an embodiment of the present invention.

FIG. 31 is a flowchart illustrating a prepay and pre-subtracting processperformed in a billing processing unit according to an embodiment of thepresent invention.

FIG. 32 is a flowchart illustrating a procedure of processing andmanaging billing data in a billing processing unit according to anembodiment of the present invention.

FIG. 33 is a block diagram illustrating a infra channel providing unitaccording to an embodiment of the present invention.

FIG. 34 is a block diagram illustrating a cooperating structure of theinfra channel providing unit according to an embodiment of the presentinvention.

FIG. 35 is a flowchart of API in an infra channel providing unitaccording to an embodiment of the present invention.

FIG. 36 is a flowchart illustrating a procedure of performing a bizobject in an infra channel providing unit according to an embodiment ofthe present invention.

FIG. 37 is a block diagram illustrating a structure of a legacycooperation processing unit in a mobile business supporting systemaccording to an embodiment of the present invention.

FIG. 38 is a block diagram illustrating the common managing unit in thelegacy cooperation processing unit according to an embodiment of thepresent invention.

FIG. 39 is a block diagram illustrating an SMS interface in a legacycooperation processing unit according to an embodiment of the presentinvention.

FIG. 40 is a block diagram illustrating an MMS interface in a legacycooperation processing unit according to an embodiment of the presentinvention.

FIG. 41 is a diagram illustrating a biz template for a MMS messagingservice according to an embodiment of the present invention.

FIG. 42 is a block diagram illustrating an LBS interface of a legacycooperation processing unit according to an embodiment of the presentinvention.

FIG. 43 is a diagram illustrating a biz template for inquiring positioninformation, as an example of a location based service (LBS) related biztemplate.

FIG. 44 is a flowchart illustrating a method of performing an LBSrelated service using a legacy cooperation processing unit having an LBSinterface according to an embodiment of the present invention.

FIG. 45 is a block diagram illustrating a push interface according to anembodiment of the present invention.

FIG. 46 is a block diagram illustrating a structure for providing adownload service in an open mobile business supporting system accordingto an embodiment of the present invention.

FIG. 47 is a flowchart illustrating a download service according to afirst embodiment of the present invention.

FIG. 48 is a flowchart illustrating a download service according to asecond embodiment of the present invention.

FIG. 49 is a flowchart illustrating a download service according to athird embodiment of the present invention.

FIG. 50 is a block diagram illustrating an operating and managementsystem (OMS) in an open mobile business supporting system according toan embodiment of the present invention.

FIG. 51 is a block diagram illustrating a web service providing unit inan open mobile business supporting system according to an embodiment ofthe present invention.

FIG. 52 is a block diagram illustrating a logic processing unitaccording to an embodiment of the present invention.

FIG. 53 is a flowchart illustrating a method of processing a mobileoriented (MO) message using an open mobile business supporting systemaccording to an embodiment of the present invention.

FIG. 54 to FIG. 55 are diagrams illustrating an MT message processingunit using an open mobile business supporting system according to afirst embodiment of the present invention.

FIG. 56 is a block diagram and a flowchart illustrating an MT messageprocessing apparatus using an open mobile business supporting systemaccording to an embodiment of the present invention.

FIG. 57 and FIG. 58 are diagrams illustrating biz template for providingan MT message in an open mobile business supporting system according toan embodiment of the present invention.

FIG. 59A and FIG. 59B are flowcharts illustrating a procedure forprocessing an MT MSM message after processing an MO SMS message using anopen mobile business supporting system according to an embodiment of thepresent invention.

FIG. 60A and FIG. 60B are diagrams illustrating a procedure ofprocessing an MT MMS message after processing an MO MMS message using anopen mobile business supporting system according to an embodiment of thepresent invention.

FIG. 61A and FIG. 61B are diagrams illustrating a procedure ofprocessing an MO SMS message after processing an MT SMS message using anopen mobile business supporting system according to an embodiment of thepresent invention.

FIG. 62A and FIG. 62B are diagrams illustrating a procedure ofprocessing an MO MMS message after processing an MT MMS message.

FIG. 63 is a block diagram illustrating a configuration for providing areport after transmitting a message in an open mobile businesssupporting system according to an embodiment of the present invention.

FIG. 64 is a detailed block diagram illustrating a report open interface(ROI) processing unit according to an embodiment of the presentinvention.

FIG. 65 is a flowchart illustrating a procedure of providing a reportthrough an open mobile business supporting system according to anembodiment of the present invention.

FIG. 66 is a flowchart illustrating the detailed operation of an ROIprocessing unit in a real time report procedure, shown in FIG. 65,according to an embodiment of the present invention.

FIG. 67 is a block diagram illustrating an open mobile businesssupporting system for confirming a message transmission result aftertransmitting a message according to an embodiment of the presentinvention.

FIG. 68 is a block diagram illustrating an ROI processing unit, shown inFIG. 67, according to an embodiment of the present invention.

FIG. 69 is a flowchart illustrating a procedure for confirming a messagetransmission result after transmitting a message in an open mobilebusiness supporting system according to an embodiment of the presentinvention, and

FIG. 70 is a diagram illustrating the operations of an ROI processingunit according to an embodiment of the present invention.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

FIG. 1 is a block diagram illustrating a network for a mobile service. Acontent provider (CP)/service provider (SP) system 11 that provides amobile service, which accesses a mobile communication system 13 throughthe Internet 12. The CP/SP system 11 provides a predetermined service toa plurality of mobile stations (MS) 14 or transmits data to theplurality of mobile stations 14.

The mobile terminal 14 denotes a small and light wireless communicationdevice so as to allow a user to carry it anywhere and anytime, such as aportable phone or a personal digital assistant. Basically, the mobileterminal 14 includes a transmitting/receiving function for transmittingand receiving a voice and data signal through a mobile communicationnetwork, a controlling function for controlling overall operationsaccording to programmed control procedures, a user interface functionfor providing a user interface to a user, a display unit for displayingmenus, messages, or graphics according to an operation state of themobile terminal in response to the control of the controlling unit. Themobile terminal 14 may include applications such as a browser.

The mobile communication system 13 denotes a system providing a wirelessvoice communication service or a wireless Internet service to the mobileterminal 14. As shown in FIG. 2, the mobile communication system 13basically includes a plurality of base transceiver stations (BTS) 21 formanaging a wireless communication region, a plurality of base stationcontrollers (BSC) 22 for controlling the BTSs 21, a mobile switchingcenter (MSC) 23 for accessing each BTS 22 and authenticating informationabout a mobile communication service subscriber, and an interworkingfunction (IWF) 24 for transforming formats of voice data and packet dataand connecting to an IP network or to another mobile communicationnetwork. The mobile communication system 13 further includes systems forproviding various additional services such as a short message servicesystem (MASS) 25 for providing a text message transfer service, amultimedia message service center (MMSC) 26 for providing a transceivingservice of a multimedia message including video, text and voice, and apush proxy gateway (PPG) 27 for providing a message push service to amobile terminal 14, and a location based service system (LBSP) 28 forproviding a service related to location information. In addition, themobile communication system 13 may include various other systems formanaging subscribers.

The MSC 23, the IWF 24, the MASS 25, the MMSC 26, the PPG 27, and theLBSP 28 are connected through an internal network of the mobilecommunication system 13 or a packet network 20.

When a predetermine mobile service is provided from the CP/SP system 11through the mobile communication system, various operations aresimultaneously performed in the mobile communication system 13, such asdownloading a corresponding service or content, user authentication, andcharging operation for using the mobile communication system 13.

For example, in order to transmit a multimedia message, a sender and areceiver are authenticated through an authentication system (not shown)of the mobile communication system, and a user's mobile terminal ischecked whether the mobile terminal has a function to receive amultimedia message through a terminal information management system (notshown). After authenticating the sender and the receiver and checkingthe model type of the user's terminal, message transmission is requestedby accessing the MMSC 500, and a billing operation is performed aftercompletely transmitting the corresponding multimedia message.

In order to provide one mobile service, the mobile communication system13 needs to cooperate with various internal systems, which is referredto as legacy systems, hereinafter. Typically, the CS/SP system 11 needto directly access each of the legacy systems of the mobilecommunication systems 13 to request necessary processes and to receivethe results thereof. In this case, the CP/SP system 11 needs interfacesfor each legacy system of the mobile communication system 13. Therefore,the structure of the CP/SP system 11 becomes complicated, and the CP/SPsystem 11 needs to exchange messages with the mobile communicationsystem 13 several times in order to provide one service, making itdifficult to provide a quick and stable service.

Hereinafter, embodiments of the present invention will be described indetail with reference to the attached drawings.

FIG. 3 is a flowchart illustrating an open mobile business supportingmethod according to an embodiment of the present invention.

Referring to FIG. 3, the open mobile business supporting methodaccording to an embodiment of the present embodiment is performed asfollows.

In the open mobile business supporting method according to an embodimentof the present embodiment, it selects logics that are performed in amobile communication system 13 and starts and ends at a content provider(CP)/service provider (SP) system 11 from logics of mobile servicesprovided from the CP/SP system 11, and standardizes the selected logics.Then, the standardized logics are provided. Therefore, in the openmobile business supporting method according to an embodiment of thepresent embodiment, low-level functions, which can be grouped as a unitfunction and can be performed in a mobile communication system, aredefined as biz logics in step S310 of FIG. 3.

Each of the biz logics is a logic that starts at the CS/SP system 11,and is performed by cooperating with legacy systems of the mobilecommunication system 13, comparing the cooperating results, making adecision based on the comparison results, and transfers the resultthereof to the CP/SP system 11. The biz logic is a set of low-levelfunctions, which can be grouped as a single function among the servicelogics provided by the CP/SP system 11. It may define the biz logic inconsideration of frequency of use and reusability in diverse CP/SPsystems 11. For example, in any types of mobile services, a generallyrequired logic, such as a user authentication process or a terminalauthentication process, has high reusability. Therefore, the userauthentication process or the terminal authentication process may bedefined as a biz logic. As another example, in case of a mobile servicefor downloading specific content or specific files to a mobilecommunication terminal 14, diverse functions, such as an authenticationprocess, a data transform process and a billing process, areconsecutively performed. The mobile service for downloading content isfrequently used. Therefore, such a mobile service for downloadingspecific content or specific files may be defined as the biz log.

The setup procedure of the biz logic will be described in detail. Instep S311, a predetermined service logic is selected through verifyingthe amount used, a usage trend, and a business aspect. Subsequently, apart corresponding to a range of the biz logic is selected from theservice logics.

FIG. 4 is a diagram illustrating services selected for defining a bizlogic in an open mobile business supporting system according to anembodiment of the present embodiment. As shown in FIG. 4, a service of“download to my phone” is selected among menus, which are providedthrough a service of a wireless Internet of the mobile communicationterminal 14. The menu includes services of “download to my phone”,“transmit to a friend”, “perform coupling” and “put in a basket.” Adetailed logic of the selected service will be described with referenceto FIG. 5.

In FIG. 5, the mobile service of “download to my phone” includes thesteps of selecting specific content by a user through the mobilecommunication terminal 14, selecting the “download to my phone” menu,requesting a user authentication process using a phone number as inputdata, determining whether the user is a normal personal user or abusiness user and whether the user is a prepaid user or an intelligentnetwork user, notifying that requested service is not available throughthe mobile communication terminal 14 if the user is an abnormal personaluser or a business user, performing a billing process that subtracts arelated fee of the requested service from the prepaid amount if the useris determined to be a prepaid user, and transmitting related content andperforming a billing operation if the user is determined as a normalpersonal user.

As shown in FIG. 6, a biz logic is determined among the selected servicelogics through range selection, objects selection, separation andoptimization.

A reference for selecting a biz logic from the service logics may be howwell functional units of the logic are collected, how well a formatadding individual logics is derived as a standardized format, howrealistically the logic is used, if the format of the logic is neutraland independent enough to be re-formed in the other case. The biz logicis separated in a case that the service logic requires a user to input,a case that input/output values of the service logic are different, anda case that the service logic is affected by external factors.

FIG. 7 is a diagram illustrating an example of the biz logic definedfrom the service logics of “download to my phone” through procedures ofFIG. 6. That is, the biz logic is divided into a biz logic forperforming a user authentication process including a prepaid balancechecking process, and a biz logic for performing a billing process thatsubtracts the related fee from the prepaid balance.

As described above, when the range of the biz logic is determined, thedetermined biz logic is analyzed in step S3122. A logic, which needs tocooperate with legacy systems of a mobile communication system 12, isset up as a first Biz object, i.e., an I-type object. A logic performinga comparing or determining process based on a cooperation result withthe legacy system is set up as a second Biz object, i.e., a P-typeobject. An input value and an output value of the first and second Bizobjects are defined.

The second Biz object can be defined as a single Biz object if manycomparing/determination steps can be performed as a single unit process.

FIG. 8 is a diagram for describing how a first biz object is set up inthe user authentication process including a prepaid balance checkingprocess as shown in FIG. 7. The first biz object is an object requestingthe user authentication process by cooperating with an authenticationlegacy system.

FIG. 9 is a diagram for describing how the second Biz object is set upin the biz logic for performing a user authentication process includinga selected prepaid balance checking process as shown in FIG. 7. Thesecond Biz object determines whether a service is provided according toa process result with the authentication legacy system. The second Bizobject is set up by classifying procedures of checking whether a user isa normal personal user or a business user, whether the user is a prepaiduser or not, and whether the prepaid user is a multilevel user or anintelligent network user.

The first and second Biz objects are respectively set up by analyzingthe logic within the determined range. The first and second Biz objectsare arranged according to the flow of a corresponding biz log. The inputand output values are defined. Accordingly, a Biz template, which is anoperation format of the corresponding biz log, is formed in step S313.The Biz template can have a format of a general flowchart. The Biztemplate includes a list of Biz objects, an attribute of each object, anoperation order of the Biz objects, description of conditional branch,input parameter information for operating the Biz objects, a datacontrolling method, output parameter information derived by operatingthe Biz template, and operation time-out setup information.

FIG. 10 is a diagram for describing the Biz template, which standardizesthe biz logic for performing a user authentication process including aselected prepaid balance checking process as shown in FIG. 7. As shownin a table on the right side of FIG. 10, the Biz template includes anI-type authentication_user information checking Biz object, a P-typeuser information checking Biz object, and an 1-typeauthentication_prepaid checking Biz object. The I-typeauthentication_user information checking Biz object checks userinformation. The P-type user information checking Biz object checkswhether the service can be provided to the user. The I typeauthentication_prepaid checking Biz object checks a prepaid balance ofthe user. A flow of the Biz template is described as shown in theflowchart on the left side of FIG. 10.

When input data of the Biz template are a user telephone number and aprice of content, output data are information on whether the processresult is successful or not, and whether the user is a prepaid user.

As described above, the Biz template is a format that the biz logic isrealized. The Biz templates including a user authentication template, aShort Message Service (SMS) transmitting template, an MMS transmittingtemplate, a general location detecting template, and a push methodplatform message transmitting template based on SMS/cell broadcastingservice (CBS) can be realized.

FIGS. 11 and 12 are diagrams for describing the Biz template accordingto another embodiment of the present invention. FIG. 11 shows a Biztemplate of the biz logic for performing a user authentication process.FIG. 12 shows a Biz template of the biz logic including a process ofdetermining whether a terminal is supported in the user authenticationprocess.

Referring to FIG. 11, the basic Biz template for performing a userauthentication process includes: (1) an I-type authentication_userinformation checking Biz object for checking user information and (2) aP-type user information checking Biz object for checking whether aservice can be provided to the user based on the user information checkresult. The input data are a user telephone number and, as an option, auser authentication type. The output data are information on whether theprocess result is a success or an error.

The Biz template of FIG. 12 includes: (1) an I-type authentication_userinformation checking Biz object; (2) a P-type user information checkingBiz object; and (3) an I-type terminal support checking Biz object. TheI-type authentication_user information checking Biz object checks userinformation. The P-type user information checking Biz object checkswhether a service can be provided to the user based on the userinformation check result. The I-type terminal support checking Bizobject checks whether a terminal supports a specific service to the userwho can receive the service. The input data are a recipient telephonenumber, a user information checking option value and a terminal supportservice type. The output data are process results.

While the biz logic is set up and the Biz template is prepared, aninterface for requesting the operation of the biz logic to the CP/SPsystem 11 and returning the result is provided. Subsequently, anoperation request of the specific biz logic is received through theinterlace in step S320.

When the operation request of the specific biz logic is received, a Biztemplate of an operation format of corresponding biz logic is searched.The Biz template cooperates with the legacy system. An operate resultvalue is returned to the CP/SP system 11 through the interface in stepsS330 and S340.

The interface with the CP/SP system 11 forms and provides ApplicationProgram Interface (API) for each Biz template. The operation request ofthe specific biz logic is realized in an API calling format of thespecific Biz template.

The open mobile business supporting method according to an embodiment ofthe present invention can support cooperation between the legacy systemsby receiving the operation request of the predetermined Biz object froma specific legacy system of the mobile communication system 12,cooperating the requested Biz object with the corresponding legacysystem, operating the cooperated Biz object, and providing a resultvalue in order to transmit the result value to the specific legacysystem transmitting the request. That is, the open mobile businesssupporting method can support fast cooperation between the legacysystems by using a typical Biz object.

Hereinafter, the configuration and operation of the open mobile businesssupporting system for performing the open mobile business supportingmethod will be described in detail.

FIG. 13 is a block diagram illustrating the structure of an open mobilebusiness supporting system according to an embodiment of the presentinvention.

Referring to FIG. 13, the open mobile business supporting systemaccording to an embodiment of the present invention includes an openinterface (OI) processing unit 100, a business logic processing unit200, an infra channel providing unit 300, a billing processing unit 400,a legacy cooperation processing unit 500, an operation and managementsystem (OMS) 700 and a web service providing unit 600.

Reference numeral 11, which is not described above, is a CP/SP systemfor providing a mobile service to the mobile communication terminal 14.Reference numeral 30 is a legacy system including a service platform, aninfrastructure system, and a network configuration device of the mobilecommunication system 13.

The service platform of the legacy system 30 includes a messagingplatform, a location based service platform (LBSP) and a downloadplatform. The messaging platform provides a multimedia messaging service(MMS). The LBSP provides a service for detecting and checking alocation. The download platform downloads predetermined content to themobile communication terminal. The infrastructure system includes aCP/SP management system, a terminal information management system and anauthentication system. The CP/SP management system manages CP/SPinformation for providing a service. The terminal information managementsystem manages terminal information. The authentication system managesuser information. The network configuration device includes a shortmessage service center (SMSC) and a cell broadcasting service center(CBSC).

As shown in FIG. 13, the open mobile business supporting systemaccording to an embodiment of the present invention provides a unitedinterface to diverse legacy systems 30, relays the CP/SP system 11 andthe legacy system 30, and supports configuration and provision of themobile service in the CP/SP system 11.

Accordingly, the OI processing unit 100 receives an operation request ofspecific biz logic from the external CP/SP system 11 of the mobilecommunication system 13. Also, the OI processing unit 100 provides aninterface for returning an operation result. The interface isapplication program interface (API) based on web access. The specificbiz logic is requested by API calling of a corresponding Biz template.The Biz template identification (ID) information and data such ascontent are transmitted through the calling function, and the resultvalue is returned. The OI processing unit 100 analyzes the requesttransmitted from the CP/SP system II and extracts the Biz template IDinformation and the data. Subsequently, the OI processing unit 100transmits the Biz template ID information and the data to the businesslogic processing unit 200. The OI processing unit 100 creates andmanages a unique session key for each request of the CP/SP system 11.The created session key is used to classify the biz logics, which areprocessed in the open mobile business supporting system.

Also, the OI processing unit 100 encodes and decodes the datatransmitted from/to the CP/SP system 11.

The business logic processing unit 200 can be classified as a unitfunction among service logics of the CP/SP system. The business logicprocessing unit 200 stores, manages and operates a plurality of Bizobjects and the Biz template. Herein, the Biz objects cooperate witheach legacy system or perform comparing and determining processes oneach legacy system of the mobile communication system realized tooperate the biz log based on cooperation with each legacy system or thecooperation result. The biz logic is a lower function to be operated bythe mobile communication system. The Biz template includes a pluralityof Biz objects arranged in a regular order and operates the biz log. Thebiz log, the Biz template and the Biz object will be understood withreference to description related to FIGS. 4 to 10 and FIGS. 11 and 12.

The business logic processing unit 200 sets up and includes the Biztemplate, which is a realization format of the supporting biz log, andBiz object. Also, the business logic processing unit 200 operates theBiz template requested by the OI processing unit 100 and returns anoperation result to the OI processing unit 100. To be more specific, thebusiness logic processing unit 200 operates the first or second Bizobject in an arranged order of the requested Biz template. Whenoperation of all Biz objects ends, the business logic processing unit200 returns the result value to the OI processing unit 100. The businesslogic processing unit 200 requests cooperation with the legacy system 30to the legacy cooperation processing unit 500 according to the kind ofthe Biz objects included in the Biz template. Subsequently, the businesslogic processing unit 200 receives back the result or performs aninternal determining process or a comparing process based on thereturned operation result.

As described above, the open mobile business supporting system accordingto an embodiment of the present invention can support a complicatedservice including diverse processes requested by the CP/SP system 11based on the business logic processing unit 200.

The open mobile business supporting system according to an embodiment ofthe present invention can support a cooperating process based onperformance requiring a fast process through the infrastructure channelproviding unit 300.

The infrastructure channel providing unit 300 does not go through the OIprocessing unit 100. However, the infra channel providing unit 300directly receives an operation request of the Biz object, which isoperated in another legacy system 30, from the legacy system 30 insidethe mobile communication system 13. The infra channel providing unit 300transmits the requested Biz object to the legacy system 30 through thelegacy cooperation processing unit 500 and receives back the processresult from the legacy system 30. Subsequently, the infra channelproviding unit 300 transmits the process result to the legacy system 30requesting the operation of the Biz object.

FIG. 14 shows diagrams illustrating operations of the business logicprocessing unit 200 and the infra channel providing unit 300 accordingto an embodiment of the present invention.

FIG. 14 (a) shows a supporting procedure of the business logicprocessing unit 200. When the business logic processing unit 200receives an operation request of the Biz template from the OI processingunit 100 in step S811, the business logic processing unit 200 performsloading on data of a corresponding Biz template from Main MemoryRegister Database Management System (MMDB) 900 in step S812. The MMDB900 is a database based on a memory and will be described with referenceto the description of FIG. 15. The business logic processing unit 200operates the second Biz object in the loaded Biz template in step S813.The business logic processing unit 200 transmits a request message tothe legacy cooperation processing unit 500 according to the first Bizobject of the Biz template in step S814. The business logic processingunit 200 repeats a procedure of receiving an acknowledge (ACK) messagein step S815 and ends the operation of the Biz template. The businesslogic processing unit 200 transmits billing information, which isacquired by ending the operation to the billing processing unit 400 instep S816, and transmits an operation result to the OI processing unit100 in step S817. Accordingly, the business logic processing unit 200can support a mobile service based on a complicated function byoperating the biz logic including at least one service and process.

FIG. 14 (b) shows a procedure of the infra channel providing unit 300.When the specific legacy system 30 requests operation of a specific Bizobject, the infra channel providing unit 300 directly receives andanalyzes the request in step S821. The infra channel providing unit 300performs an internal process according to the requested Biz object instep S812, requests the legacy cooperation processing unit 500 tocooperate in step S813 and receives an ACK of the request in step S814.The infra channel providing unit 300 transmits related billinginformation to the billing processing unit 400 in step S815 andtransmits an operation result to the legacy system 30 requesting theservice in step S816.

As described above, the mobile business supporting system according toan embodiment of the present invention directly processes cooperationbetween the internal systems of the mobile communication system notthrough the OI processing unit 100 but through the infra channelproviding unit 300. Also, the mobile business supporting systemprocesses the request of the external CP/SP system 11 through the OIprocessing unit 100 and the business logic processing unit 200.Accordingly, the mobile business supporting system can improve thequality of a service by separately supporting the service based on thecomplicated function and the service based on performance.

In FIG. 13, the legacy cooperation processing unit 500 is in charge ofcooperation with the legacy system 30. The legacy cooperation processingunit 500 includes a plurality of cooperation units for processing aninput/output interface function, a log of each legacy system and billinginformation. The input/output interface function is respectivelystandardized for each legacy system classified on the basis offunctional unit for an efficient process. The legacy cooperationprocessing unit 500 includes an SMS cooperation unit, a location basedservice (LBS) cooperation unit, an MMS cooperation unit, and anauthentication cooperation unit. The SMS cooperation unit transmits atransmission request of a short message to the SMSC and returns theresult. The LBS cooperation unit cooperates with the LBSP, transmits alocation checking or detecting request message and receives back theoperation result. The MMS cooperation unit transmits a multimediamessage transmission request message to the MMSC and receives back theoperation result. The authentication cooperation unit transmits anauthentication request message to the authentication legacy systemrelated to a process for checking whether the user is a normal personaluser, and a billing process inside the mobile communication system 13.Subsequently, the authentication cooperation unit receives back theresult.

The billing processing unit 400 collects billing data acquired byoperating the Biz template and the Biz object of the business logicprocessing unit 200 and the infra channel providing unit 300 andtransmits the billing data to the billing legacy system. To be morespecific, the billing processing unit 400 refers to a billing conditionset up for each service. When the billing condition is satisfied inoperation of each of the Biz template or the Biz object, the billingprocessing unit 400 collects billing information for a correspondingprocess, e.g., a quantity of data and a log time, transforms the billinginformation into billing data and transmits the billing data to thelegacy system for processing billing. As described above, the billingprocessing unit 400 is formed on the same layer as the business logicprocessing unit 200 and the infra channel providing unit 300.Accordingly, the billing processing unit 400 can respectively collectlog information for each mobile service and for each legacy system. Itmakes an integration process of billing possible, and detailedinformation is provided.

The open mobile business supporting system according to an embodiment ofthe present invention can further include the web service providing unit600 for providing services of registering CP/SP or manager, checkingstatistics information related to performance of the open mobilebusiness service, and monitoring. The web service providing unit 600provides a site for the manager and a site for the CP/SP.

The open mobile business supporting system according to an embodiment ofthe present invention includes the OMS 700. Therefore, the open mobilebusiness supporting system can collect log information on the openmobile business supporting service, monitor obstacle and performanceinformation and manage information for supporting operating work. Thatis, the open mobile business supporting system collects log informationfor each CP/SP through the OI processing unit 100 and collects operationand obstacle information of the business logic processing unit 200 andthe legacy cooperation processing unit 500. Subsequently, the openmobile business supporting system provides the operation and obstacleinformation to the CP/SP or the operator.

FIG. 15 is a diagram illustrating the structure of an open mobilebusiness supporting system according to an embodiment of the presentinvention.

Referring to FIG. 15, the open mobile business supporting systemaccording to an embodiment of the present invention includes the OIprocessing unit 100, the business logic processing unit 200, the infrachannel providing unit 300, the billing processing unit 400, the legacycooperation processing unit 500, the web service providing unit 600, andthe OMS 700. In addition, the open mobile business supporting systemincludes a message transferring unit 800. The message transferring unit800 includes a plurality of message queues (MQ) for transmitting asignal between the OI processing unit 100 and the business logicprocessing unit 200, and a signal between the business logic processingunit 200 and the legacy cooperation processing unit 500 or a signalbetween the infra channel providing unit 300 and the legacy cooperationprocessing unit 500. In the open mobile business supporting systemaccording to an embodiment of the present invention, the messagetransferring unit 800 asynchronously processes message exchange amongthe OI processing unit 100, the business logic processing unit 200, theinfra channel providing unit 300, the billing processing unit 400, andthe legacy cooperation processing unit 500 through the message queue.

Also, the open mobile business supporting system according to anembodiment of the present invention further includes the MMDB 900 tomanage a request of the Biz template, an operation result and a statusof Biz object/Biz template. The OI processing unit 100, the businesslogic processing unit 200 and the infra channel providing unit 300 canaccess to the MMDB 900 and perform recording and reading processes. Whenthe OI processing unit 100 records the requested Biz template in theMMDB 900, the business logic processing unit 200 operates the Biztemplate with reference to a pre-database based on a memory in the MMDB900 and uses the pre-database to record the status. The MMDB 900 storesinformation on the Biz template. When the OI processing unit 100 and thebusiness logic processing unit 200 request the information on the Biztemplate, the MMDB 900 provides information on a corresponding Biztemplate.

Generally, the MMDB is a database (DB) located and operated in a mainmemory of a computer. Since the MMDB is located in the main memorydifferently from a typical DB stored and used in hard disk (HDD), theMMDB does not require a work for reading data. Also, the MMDB can use aquery of the typical DB without change in a general status that anentire DB table is in the main memory. Accordingly, the speed ofsearching, comparing and analyzing data increases. That is, the MMDB 900according to an embodiment of the present invention can process thecomplicated biz logic at a high speed by storing the requested Biztemplate information and status information.

The open mobile business supporting system according to an embodiment ofthe present invention further includes a repository DB 1000 for storingand managing CP/SP information and service/content information.

Referring to the repository DB 1000, the web service providing unit 600provides registration and change of the CP/SP, a monitoring service, andnewly added biz logic information including the API of each Biztemplate. The OMS 700 manages obstacle and performance information withreference to the MMDB 900 and the repository DB 1000.

The message transferring unit 800 of FIG. 15 includes a plurality ofmessage queues allocated to each system. The OI processing unit 100records a request message of a predetermined Biz template in adesignated message queue of the message transferring unit 800. Thebusiness logic processing unit 200 reads a Biz template request messagein a designated message queue of the message transferring unit 800 andoperates each Biz object included in the Biz template in an order. Thefirst Biz object records a cooperation request message of apredetermined legacy system inside the message transferring unit 800.The first Biz object reads and processes the request message in thedesignated message queue of the message transferring unit 800 of thelegacy cooperation processing unit 500. Subsequently, the first Bizobject records the result in a predetermined message queue of themessage transferring unit 800. The business logic processing unit 200reads a process result of the first Biz object in the message queue andcontinues to a next process. As described above, the business logicprocessing unit 200 can secure independent operation of the OIprocessing unit 100, the business logic processing unit 200, the infrachannel providing unit 300, and the legacy cooperation processing unit500 by transmitting a message through the message transferring unit 800.

FIG. 16 is a diagram illustrating a detailed configuration and a messagetransmitting flow of the message transferring unit 800 according to anembodiment of the present invention.

Referring to FIG. 16, a message queue included in the messagetransferring unit 800 is divided into first, second, third, fourth andfifth message queues 811, 812, 813, 814 and 815. At least one firstmessage queue 811 stores a request message of the OI processing unit 100that the business logic processing unit 200 is to receive. At least onesecond message queue 812 is set up for each legacy cooperationprocessing unit 500 and stores a request message that the business logicprocessing unit 200 provides to the corresponding legacy cooperationprocessing unit 500. At least one third message queue 813 stores aresult message of the legacy cooperation processing unit 500 that thebusiness logic processing unit 200 is to receive. At least one fourthmessage queue 814 stores a report message of the legacy cooperationprocessing unit 500 that the business logic processing unit 200 is toreceive. At least one fifth message queue 815 stores a result message tobe transmitted from the business logic processing unit 200 to the OIprocessing unit 100.

Information showing the first to fifth message queues 811 to 815, i.e.,a message queue name, includes a name of a system, which transmits astored message, a name of a system to receive the stored message, a kindof messages showing whether the stored message is an ACK message, arequest message or a report message, and a domain or an ID value set upfor each input/output processor (IOP). Based on the information, each ofthe OI processing unit 100, the business logic processing unit 200 andthe legacy cooperation processing unit 500 can identity a message queuefor recording or reading its own request/ACK/report message.

FIG. 17 is a flowchart illustrating an operation of the open mobilebusiness supporting system according to exemplary embodiment of thepresent invention. Referring to FIG. 17, the OI processing unit 100according to an embodiment of the present invention receives standardAPI calling for a predetermined biz logic from the CP/SP system 11,checks a Biz template related to the called API and transmits anoperation request message of a corresponding Biz template to thebusiness logic processing unit 200 in steps S1100 and S1102. The OIprocessing unit 100 transmits the Biz template request message to thefirst message queue 811 of the message transmitting unit 800 in order totransmit the operation request message of the Biz template.

The business logic processing unit 200 checks whether the operationrequest message of the Biz template exists in the first message queue811 of the message transferring unit 800. If the new operation requestmessage of the Biz template exists, the business logic processing unit200 reads the operation request message of the Biz template in the firstmessage queue 811 in step S1104. Subsequently, the business logicprocessing unit 200 performs loading on Biz template information relatedto the request message from the MMDB 900 in step S1106 and operates aflow of the loaded Biz template in step S1108.

If the Biz object of the Biz template is an I-type during the operation,the business logic processing unit 200 requests the operation of the Biztemplate by storing a message, which requests the legacy cooperationprocessing unit 500 to cooperate, in a second message queue 812 in stepS1110. The second message queue 812 is allocated to each system of thelegacy cooperation processing unit 500. The corresponding legacycooperation processing unit 500 reads and processes the recorded messageand records an ACK message or a report message for an operation resultin the third and fourth message queues 813 and 814.

Therefore, the business logic processing unit 200 can receive the ACK orreport message for the request from the designated third and fourthmessage queues 813 and 814 in step S1112. If the process of the Biztemplate does not end, the procedures of the steps S1110 and S1112 arerepeated.

When the process of a corresponding Biz template ends in step S1114, thebusiness logic processing unit 200 transmits billing information relatedto the process to the billing processing unit 400 in step S1116.

Also, the business logic processing unit 200 stores the Biz templateoperation result in the fifth message queue 815 of the messagetransferring unit 800 and transmits the Biz template operation result tothe OI processing unit 100 in step S1118.

The OI processing unit 100 retransmits the transmitted Biz templateoperation result to the CP/SP system 11 in step S1120.

In the open business supporting system according to an embodiment of thepresent invention, the OI processing unit will be described in detailwith reference to FIG. 18.

FIG. 18 is a block diagram illustrating the OI processing unit accordingto an embodiment of the present invention. FIG. 18 shows a format inwhich the OI processing unit is realized in the open mobile businesssupporting system. Referring to FIG. 18, the OI processing unit 100according to an embodiment of the present invention includes a webservice unit 101, an authenticating unit 102, a session key creatingunit 103, a cooperation managing unit 104, a message analyzing andtransforming unit 105, and a message processing unit 106. The OIprocessing unit 100 according to an embodiment of the present inventioncan further include a session managing unit 107, a log managing unit108, a configuration managing unit 109, and a configuration informationtransmitting unit 110.

In the OI processing unit 100, the web service unit 101 receives astandard API input with respect to the operation request of the Biztemplate from the CP/SP system 11 and transmits the Biz templateoperation result to the CP/SP system 11. The web service unit 101 andthe CP/SP system 11 cooperate in a format of a web service based onSimple Object Access Protocol (SOAP). The CP/SP system 11 creates a stubfor the SOAP based on a web service toolkit provided for each platformand can use the web service as general function calling. Also, the CP/SPsystem 11 requests the operation of the Biz template by the web serviceunit 101 through the standard API and receives the operation result.

The authenticating unit 102 performs and manages an authenticationprocess of the Biz template requesting the operation of the CP/SP system11. In addition, the authenticating unit 102 performs and manages anauthentication process of the CP/SP system 11. The authenticating unit102 constraints access to an II) of the specific CP/SP system 11 and aspecific Internet protocol (IP).

The session key creating unit 103 creates a session key for the Biztemplate whose operation is requested by the CP/SP system 11. Thesession key is a unique key with respect to each Biz template. Thesession managing unit 107 manages the unique session key created in thesession key creating unit 103. The unique session key is mapped with Biztemplate information corresponding to the MMDB 900 and stored.Therefore, the unique session key is allocated to the Biz templateinformation whose operation is request by the CP/SP system 11. The Biztemplate information is stored in the MMDB 900. Subsequently, thebusiness logic processing unit 200 receives the session key from the OIprocessing unit 100 and searches Biz template information in the MMDB900 based on the session key. The business logic processing unit 200operates the searched Biz template and records the status information inthe MMDB 900.

The cooperation managing unit 104 has a thread for the operation requestof the Biz template of the CP/SP system 11 transmitted to the webservice unit 101 stand by. When the business logic processing unit 200transmits the Biz template operation result, the cooperation managingunit 104 activates the stand-by thread and transmits the Biz templateoperation result to the web service unit 101. The web service unit 101receives standard API input for the operation request of the Biztemplate from the CP/SP system 11 and transmits the standard API inputto the cooperation managing unit 104. The cooperation managing unit 104transmits the standard API input to the message processing unit 106 andmaintains the thread for the standard API input in a stand-by status.When the cooperation managing unit 104 receives the Biz templateoperation result from the message processing unit 106, the cooperationmanaging unit 104 activates a process thread of the web service unit 101and transmits the operation result to the web service unit 101.

In particular, the OI processing unit 100 according to an embodiment ofthe present invention controls synchronous cooperation with the CP/SPsystem 11 and controls asynchronous cooperation with the business logicprocessing unit 200. That is, when the OI processing unit 100 accordingto an embodiment of the present invention receives the standard APIinput for the Biz template from the CP/SP system 11, the OI processingunit 100 maintains a session with the CP/SP system 11 until the OIprocessing unit 100 returns the Biz template operation result to theCP/SP system 11. Subsequently, the OI processing unit 100 performsasynchronous cooperation. However, when the OI processing unit 100according to an embodiment of the present invention transmits theoperation request message of the Biz template to the business logicprocessing unit 200, the OI processing unit 100 transmits the requestmessage to the first message queue 811 of the message transferring unit800 and searches an operation result message of the Biz template in thefifth message queue 815. If the operation result message of the Biztemplate exists, the OI processing unit 100 asynchronously cooperateswith the business logic processing unit 200 by reading and transmittingthe operation result message to the CP/SP system 11 through the webservice unit 101.

The message analyzing and transforming unit 105 receives the operationresult message from the CP/SP system 11 or the business logic processingunit 200 and transforms the operation result message to be transmittedto the business logic processing unit 200 or the CP/SP system 11. Thatis, the message analyzing and transforming unit 105 analyzes thestandard API input transmitted from the CP/SP system 11 and transformsthe standard API input into the operation request message of the Biztemplate readable by the business logic processing unit 200. Also, themessage analyzing and transforming unit 105 transforms the Biz templateoperation result transmitted from the business logic processing unit 200into a message to be transmitted to the CP/SP system 11.

The message processing unit 106 transmits/receives the operation requestmessage of the Biz template or the operation result message of the Biztemplate to/from the business logic processing unit 200. That is, themessage processing unit 106 receives the operation request message ofthe Biz template transformed in the message analyzing and transformingunit 105 and records the operation request message of the Biz templatein the first message queue 811 of the message transferring unit 800. Themessage processing unit 106 reads the operation result message of theBiz template, which is recorded in the fifth message queue 815, in thebusiness logic processing unit 200 and transmits the operation resultmessage of the Biz template to the message analyzing and transformingunit 105. The message processing unit 106 asynchronouslytransmits/receives the operation request message or the operation resultmessage of the Biz template by control of the cooperation managing unit104.

As described above, the OI processing unit 100 according to anembodiment of the present invention provides an interface as a point ofcontact for the CP/SP system 11, which is a client requiring a serviceof the open mobile business supporting system. The OI processing unit100 receives diverse service requests from the CP/SP system 11 through aweb interface. In particular, in the mobile business supporting system,the OI processing unit 100 according to an embodiment of the presentinvention provides a business logic calling mechanism of a standard APIformat from the CP/SP system 11. The open interface, which has the CP/SPsystem 11 that can easily use a function of a wireless internetinfrastructure system without directly developing the wireless Internetinfrastructure system differently from a typical cooperating methodbased on a protocol, is provided. The open interface can be used withoutlimitation of the kind of the CP/SP system as a client.

As described above, in FIG. 17, the OI processing unit 100 according toan embodiment of the present invention can further include the sessionmanaging unit 107, the log managing unit 108, the configuration managingunit 109, and the configuration information transmitting unit 110.

The session managing unit 107 manages session information in the MMDB900. The MMDB 900 stores authentication information of the CP/SP system11, the operation result of the Biz template and status information. TheBiz template information whose operation is requested by the CP/SPsystem 11 and the unique session key allocated to the Biz template aremapped and stored in the MMDB 90. An important function of cooperationof the MMDB 900 is storing a session status, a Biz object status,session parameter information, and Biz object parameter information. Tobe more specific, the session status is stored in case of operation ofthe session for processing a service requested from outside, change ofthe session status or end of the service process. When the sessionstarts, the session parameter is stored. Also, when an object isoperated to process the service after start of the session, the objectstatus and an object parameter value are stored.

The log managing unit 108 manages operation of the Biz templatetransmitted from the business logic processing unit 200, log informationon an error, statistics data, and session information on an endedtransaction. The log managing unit 108 creates a system log related tothe log and transmits the created log information and statistics data tothe OMS 700.

The configuration managing unit 109 manages configuration information onthe OI processing unit 100 by providing a function for accessing theenvironment setup file of the OI processing unit 100 according to anembodiment of the present invention. The configuration managing unit 109reflects change of the configuration information of the 01 processingunit 100 according to an embodiment of the present invention in realtime. Accordingly, a module requiring corresponding configurationinformation can check a changed configuration information value.

The configuration information transmitting unit 110 receives aconfiguration information checking request of the OI processing unit 100through an external system web site 55. The configuration informationtransmitting unit 110 extracts and transmits the configurationinformation to the web site. When the configuration informationtransmitting unit 110 receives the configuration information checkingrequest of the OI processing unit 100 according to an embodiment of thepresent invention through the web site 55 realized by the web serviceproviding unit 600, a configuration information on-line checking moduleextracts a configuration information value, and the configurationinformation transmitting unit 110 transmits the configurationinformation value extracted by the web service through the web site 55.A developer of the web site 55 can check the configuration informationtransmitted through the web service on a configuration informationchecking screen of the OI processing unit 100.

The open mobile business supporting system 100 according to anembodiment of the present invention can have more than two OI processingunits 100 to support more users. Herein, since the business logicprocessing unit 200 reads and processes the request message of the OIprocessing unit 100 in an order, the OI processing unit 100 cangenerally use the first message queue 811. However, since destinationsof messages of each session are different, the fifth message queue 815sets up a message queue for each OI processing unit 100. When therequest message is recorded, the fifth message queue 815 includesinformation on a message queue to return a result value. Accordingly, itis possible to figure out in which part of the business logic processingunit 200 the result value of the Biz template is recorded.

FIG. 19 is a flowchart illustrating a detailed operation of the OIprocessing unit 100 in the open mobile business supporting systemaccording to an embodiment of the present invention.

Referring to FIG. 19, the web service unit 101 receives a standard APIinput for a specific operation request of the Biz template from theCP/SP system 11 in step S1300. A thread for the operation request of theBiz template of the CP/SP system 11, which the web service unit 101receives, remains in a standby status. When the operation result of theBiz template is received, the thread is activated and the Biz templateoperation result is transmitted to the web service unit 101.

The session key creating unit 103 creates a unique session key withrespect to the Biz template, whose operation is requested, in stepS1302. The created session key is mapped with a corresponding Biztemplate and stored in the MMDB 900. The authenticating unit 102authenticates the Biz template in step S1304. The authenticating unit102 also authenticates the CP/SP system 11 providing the operationrequest of the Biz template.

In step S1306, the message analyzing and transforming unit 105transforms the operation request of the Biz template into a messageformat, which is readable by the business logic processing unit 200, totransmit the operation request of the Biz template to the business logicprocessing unit 200. The message processing unit 106 transmits thetransformed operation request message of the Biz template to thebusiness logic processing unit 200 in step S1308 and waits to receivethe operation result message of the Biz template in step S1310. Themessage processing unit 106 records the operation request message of theBiz template in the first message queue 811 of the message transferringunit 800 to transmit the operation request message of the Biz templateto the business logic processing unit 200. Subsequently, the messageprocessing unit 106 waits until the operation result message of the Biztemplate arrives at the fifth message queue 815 of the messagetransferring unit 800.

When the operation result message of the Biz template arrives at thefirst message queue 811 in step S1312, the operation result message ofthe Biz template is transformed into a message format to be transmittedto the CP/SP system 11 in step S1314. Subsequently, the transformedoperation result message of the Biz template is transmitted to the CP/SPsystem 11 through the web service 101 in step S1316.

Hereinafter, the standard API provided to the CP/SP system 11 throughthe OI processing unit 100 will be described in detail.

The OI processing unit 100 according to an embodiment of the presentinvention provides a service for using the open mobile businesssupporting system based on an invoke API function.

The API is provided according to each Biz template provided in the openmobile business supporting system. For example, the API is set upaccording to each request by a user authentication process including aprepaid balance checking process and a terminal supporting checkingprocess, a phone model information checking process, a number changechecking process, a phone model information checking process, an SMStransmitting process, an MMS transmitting process, a general locationsearching process, a pushing method, a platform message transmittingprocess, a transmitting process to another company, and a transmittingprocess to my phone.

The provided API is basically using the invoke API function. The APIrequests operation of a specific Biz template by using TEMPLATE_ID,which is a Biz template ID showing the Biz template to be operated,AUTH_KEY, which is an authentication key given to use the Biz template,inParamSet, which is an input parameter for transmitting informationrequired for operation of the Biz template, and outParamSet, which is anoutput parameter showing result information returned after the operationof the Biz template, as a parameter. Accordingly, the API can acquireresult information. The output parameter basically includes a resultcode showing whether the service request succeeds or fails, and a reasonof failure in case that the service request fails and a result messageshowing the operation result value. The result code returns a “0” valuein case that the service request succeeds. When the service requestfails, i.e., there is an error in the service request thereof, a codeset up according to the kind of each error is returned. A list andcontent of the provided error code are provided in advance to the CP/SP.

In the input parameter and the output parameter, content of informationtransmitted from the parameter are changed according to the kind ofcorresponding API.

To be more specific, the open mobile business supporting systemaccording to an embodiment of the present invention provides the API fora basic user authentication process such as a process for checkingwhether the user is a normal personal user, cutting offsuspension/termination, cutting off a business user, cutting off aprepaid user, and cutting off intelligent network prepayment. As aninput parameter, the API includes a user phone number and a userauthentication type showing the basic user authentication process suchas a process for checking whether the user is a normal personal user,cutting off suspension/termination, cutting off a business user, cuttingoff a prepaid user, and cutting off intelligent network prepayment. Asan output parameter, the API includes the result code and the resultmessage. The result code shows the success or failure and the kind oferror in case that the user authentication request fails.

In addition, the open mobile business supporting system according to anembodiment of the present invention can set up the API further includinga prepaid balance checking process as well as the basic userauthentication process. As the input parameter, the API further includesprice information on the content service provided with the user phonenumber and the user authentication type. As a return value, the API asthe output parameter includes information on whether the user is aprepaid user, and balance information of the user when the user is notthe prepaid user in addition to the request result code and the resultmessage. When the user is the normal personal user, but not the prepaiduser, the API has the CP/SP system 11 take proper measures bytransmitting a corresponding error code value through the result codeamong the output parameters.

Also, the open mobile business supporting system according to anembodiment of the present invention provides the API for authenticatingthe user and checking whether the terminal is supported according to thekind of the service. The API can acquire information on whether theterminal is supported according to the kind of the service in case thatbasic user authentication process is performed by request according tothe authentication types and the authentication is successful. The inputparameter includes the user phone number, the user authentication typeand service information on whether the service to be supported by theterminal corresponds to the MMS, flash or MP3. The output parameterincludes the result code showing whether the request thereof issuccessful and the result message.

Also, the open mobile business supporting system according to anembodiment of the present invention provides the API for checkinginformation on a phone model of a mobile communication subscriber toacquire model information on the corresponding mobile communicationterminal. As the input parameter, the API includes only the user phonenumber. The output parameter includes the result code, the resultmessage, and many values showing phone information, e.g., a phone modelname, a bell type code, poly information, color information, informationon whether Code Division Multiple Access (CDMA) or karaoke is supported.The result code shows whether the phone model checking request resultsucceeds.

Also, the open mobile business supporting system according to anembodiment of the present invention can include the API for checkingwhether the user is a subscriber receiving a specific service at amonthly fixed-rate. As the input parameter, the API includes a serviceID value set up for each service, a user phone number, a userauthentication type, an ID value of the CP/SP providing the service, aprice of corresponding content. As the output parameter, the APIincludes a result code showing a success code and an error code of amonthly fixed-rate authentication process and the prepaid balancechecking request, and a result message for transmitting a request resultvalue.

The open mobile business supporting system according to an embodiment ofthe present invention can include the API for checking only on whetherthe user is a subscriber receiving a specific service at a monthlyfixed-rate. As the input parameter, the API includes a service ID valueset up for each service, a user phone number, a user authenticationtype, and an ID value of the CP/SP providing the service. As the outputparameter, the API includes an authentication process of a monthlyfixed-rate, a result code showing a success code and an error code of amonthly fixed-rate authentication process, and a result message fordescribing an operation result value for the request.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for respectively performing asubscription or termination process on a specific service provided at amonthly fixed-rate. As the input parameter, the API includes a serviceID value set up for each service, a service code value, ID informationof a content provider, and a phone number for performing thesubscription or termination process. As the output parameter, the APIincludes a result code providing information on success or error of therequest thereof and a result message for transmitting a request valuethereof.

Also, the open mobile business supporting system according to anembodiment of the present invention can provide the API for checkinginformation on a wireless Internet user of a specific ID. As the inputparameter, the API includes wireless Internet user ID and an encodedpassword of the user. As the output parameter, the API includes a resultcode showing information on success or error of the request thereof, aresult message showing an operation result value of the request, andbasic information of a corresponding wireless Internet user, e.g., aphone number, a name, and a resident registration number.

The open mobile business supporting system according to an embodiment ofthe present invention can provide the API for checking a phone number ofa wireless Internet user of a specific ID. As the input parameter, theAPI has a wireless Internet ID. As the output parameter, the API has aresult code, a result message, a phone number and/or a name of anauthentication object.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for checking whether the user isauthenticated through a resident registration number. As the inputparameter, the API includes a user authentication type described in theAPI for a basic user authentication process, a phone number of anauthentication object, a resident registration number or a businessregistration number of an encoded authentication object, anauthentication type showing to which authentication object correspondsamong a nominee, a businessman, and an actual user. As the outputparameter, the API includes only a result code and a result message.

Also, the open mobile business supporting system according to anembodiment of the present invention provides the API for checking colorinformation provided according to each phone. As the input parameter,the API includes information on a phone to be checked, such as a modelname or a phone number. As the output parameter, the API includes aresult code, a result message and color information of a correspondingphone, e.g., a single color, 4 gray scales and 256 colors.

The open mobile business supporting system according to an embodiment ofthe present invention includes the API for checking number portabilityinformation on a carrier switching subscriber. As the input parameter,the API inputs a user phone number. As the output parameter, the APIoutputs a result code showing success or error information of a requestthereof, a result message recording an operation result value of therequest, and final routing information of number portability.

Also, the open mobile business supporting system according to anembodiment of the present invention includes the API, which provides ageinformation for determining whether the user is an adult. As the inputparameter, the API inputs a user phone number. As the output parameter,the API returns a result code showing success or error information of arequest thereof, a result message showing an operation result value andan age code showing a user's age.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for checking phone modelinformation. As the input parameter, the API inputs a user phone numberor a phone model name. As the output parameter, the API provides successor error information of a request thereof, a result message and phoneperformance information including a phone model name, a bell type, polyinformation, color information, information on whether CDMA or karaokeis supported.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API performing prepayment andpre-subtraction processes for a billing process that subtracts therelated fee from the prepaid balance in advance. As the input parameter,the API inputs an object phone number, a prepaid subscription productcode, a subtraction request cost, and a billing pattern. As the outputparameter, the API acquires a prepaid subtraction result.

The open mobile business supporting system according to an embodiment orthe present invention provides the API used in transmission of the SMS.As the input parameter, the API includes information required for SMStransmission such as an SMS type showing to which message correspondsamong a short message, a call back message and a platform message, atelephone number for reply or a call back telephone number in case thata uniform resource locator (URL) is designated, a URL, a transmissionmessage, a phone number of a caller, a phone number of a recipient andbilling pattern information. As the output parameter, the API includes aresult code showing whether the SMS transmission request thereof is asuccess, a result message and a session key allocated in the open mobilebusiness supporting system for checking a transmission result.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for transmitting an SMS monotonebell sound. As the input parameter, the API includes a call backtelephone number, a transmission message, a phone number of a caller, aphone number of a recipient, platform ID information, and billinginformation. As the output parameter, the API includes a result codeshowing whether the request thereof is a success or an error, a resultmessage and a session key given to the request to check a transmissionstatus.

In addition, the open mobile business supporting system according to anembodiment of the present invention provides the API for checking theSMS transmission result. When a corresponding API is requested, the openmobile business supporting system checks an SMS transmission result ofthe session key inputted as a parameter and returns a result. As theinput parameter, the API includes the session key returned after an SMStransmission request. As the output parameter, the API includes a resultcode showing whether the check result is a success and a result messagedescribing the check result.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for transmitting a multimediamessage to a phone of a recipient requested by a caller. When the APIinternally includes a basic authentication process for the caller andthe recipient, it is not required to call the API for a special userauthentication process. When the API is requested, the open mobilebusiness supporting system determines the kind of terminal to receive amultimedia message. In case of a terminal loading a browser, the openmobile business supporting system transmits an SMS of a call back URLmethod. When the terminal user presses a button, the open mobilebusiness supporting system downloads and displays MMS content of thecall back URL to the terminal. In case of a terminal not supporting theMMS, but supporting the SMS only, the open mobile business supportingsystem reports that transmission is not possible. As the inputparameter, the API includes a transaction ID of the MMSC, a VAS ID, acall back mobile phone number, a message transmitting method,information on whether there is a content transform request, a title andcontent of a message, platform ID) information, a caller phone number, arecipient phone number, billing information, and a billing pattern. Asthe output parameter, the API includes a result code showing success orerror information of the request thereof, a result message and a sessionkey allocated to the request. Accordingly, the CP/SP can check atransmission result of the requested multimedia message. The content ofthe multimedia message provided as the input parameter are described asan HTTP message including an HTTP header and a content area. The headerand the content region are classified into CRCF. The content regionincludes a parameter entity and a series of media entities. Theparameter entity has a parameter required for a multimedia messageservice. The series of media entities are included in the multimediamessage. The sequence of the entity is not important. However, if theparameter entity having the multimedia message service parameter exists,the entity should be located in a first place. A Hypertext MarkupLanguage (HTML) document configuring a frame of all media entitiesinside the multimedia message should be included as a first entity amongthe media entities. Each entity can include its own header field.

In addition, the open mobile business supporting system according to anembodiment of the present invention further provides the API forchecking a transmission result of the transmitted multimedia message. Asthe input parameter, the API includes a session key returned through theAPI for transmitting the multimedia.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API detecting a location of aspecific phone to support the LBS. As the input parameter, the APIincludes a user authentication type in case that authentication isincluded, a positioning method, ACK time setup information, a returningmethod such as whether to receive location information, or to receivethe location information with a map, a format of the map in case thatthe map is received, color and screen information, a caller phonenumber, a recipient phone number, billing information, service platform(SP) registered in the LBSP, a code and a service code. As the outputparameter, the API includes a result code displaying a success or anerror of the request thereof, a result message, a location value such asX and Y coordinates, an error range, encoded address information, anerror range, a positioning result time, a positioning method, a providedmap name, information on whether a map viewer is loaded, a map scale,and an encoded image file. As the output parameter, the API alsotransmits checked location information. If a time for detecting alocation by a Global Positioning system (GPS) takes long, a reservationnumber can be returned and the location should be rechecked through thereservation number.

Accordingly, a rechecking API is further provided. As the inputparameter, the API includes a request type such as binary runtimeenvironment for wireless (BREW), a cable, KUN, ME, Wireless InternetPlatform for Interoperability (WIPI), a reservation number returned bythe location checking process, a platform division information, acaller/recipient phone number, billing information, a billing pattern, aservice platform (SP) registered in the LBSP, and a service code. Theoutput parameter is formed in the same manner as the API for a locationchecking process is formed.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for adding or deleting mutualauthentication of location detection. In case of addition of mutualauthentication as the input parameter, the API includes userauthentication information, information on a request type such as BREW,KUN, ME and WIPI, a caller phone number, a version of a caller browser,a mobile phone number of a receiver, a service platform registered inthe LBSP, and a service code. In case of deletion of mutualauthentication, the API includes a request type, a caller phone number,a recipient phone number, a service platform registered in the LBSP, aservice code, a requesting subject of a tracer or a traced as the inputparameter. As the output parameter, the API includes a result codeshowing success or error information of a request thereof and a resultmessage returning a result value.

Also, the open mobile business supporting system according to anembodiment of the present invention provides the API for checking themutual authentication list in a positioning service. As the inputparameter, the API includes a user authentication type, a request typesuch as BREW, a cable, KUN, ME and WIPI, a caller phone number, aversion of a recipient browser, information on whether the requestor isthe tracer or the traced, a service platform registered in the LBSP, anda service code. As the output parameter, the API includes a result coderecording a success or error code of a request thereof, a result messagedescribing a result value, and a check list.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API for requesting setup of a triggerthrough a parameter among LBSs. The API includes a user authenticationtype, a request type such as BREW, a cable, KUN, ME and WIPI, a callerphone number, a caller browser version, the traced telephone number, astart or end time, a trigger interval, a positioning method, and URL forputting a result after performing the trigger. As the output parameter,the API includes a result code describing a success or error code of therequest thereof, a result message describing a result value, and atrigger ID) set up for each trigger. The trigger ID is used to delete orminutely check a corresponding list.

The open mobile business supporting system according to an embodiment ofthe present invention provides the API requesting cancel of the set uptrigger. As the input parameter, the API includes a request type such asBREW, a cable, KUN, ME and WIPI, a caller phone number, a caller browserversion, a trigger ID acquired by checking the trigger, a serviceplatform registered in the LBSP, and a service code. As the outputparameter, the API receives back a result code describing a success orerror code of a request thereof, a result message describing a resultvalue, and a traced telephone number.

The configuration of the API described above is only an embodiment ofthe present invention. According to the described method, the API isformed for each Biz template provided in the open mobile businesssupporting system and provided to the CP/SP system 11. The CP/SP system11 can easily acquire performance of a desired service and a resultvalue by requesting the provided API regardless of adding or changing ofa new infrastructure inside the mobile communication system.

As described above, since the open mobile business supporting systemprovides the API, the CP/SP is supported to use an internalinfrastructure of the mobile communication system based on astandardized and verified method. Accordingly, a fast and stable mobileservice can be provided.

The API may be properly changed and managed according to the receptionof a new mobile service, change/addition of the infrastructure of themobile communication system, change/addition/deletion of the Biztemplate. When a new API is created, commonness, readability andindependence of the API may be secured. The commonness means that theAPI can be commonly used in diverse services. The readability means thatmobile service developers can form a new business model by easilyunderstanding the API. The independence means that the API isindependent from a pre-distributed API.

Referring to FIG. 20, the business logic processing unit in the mobilebusiness supporting system according to an embodiment of the presentinvention will be described in detail.

FIG. 20 is a block diagram illustrating a detailed configuration of thebusiness logic processing unit 200. The business logic processing unit200 according to an embodiment of the present invention includes a firstconforming unit 201, a first message analyzing and transforming unit202, a template operating unit 203, an object operating unit 204, atemplate loading unit 205, a template managing unit 206, a secondmessage analyzing and transforming unit 207, and a second conformingunit 208.

The business logic processing unit 200 according to an embodiment of thepresent invention can further include at least one of a session managingunit 209, a repository managing unit 210, a log managing unit 211, a DBcooperating unit 212, a time-out creating unit 213, a configurationinformation managing unit 214, a configuration information transmittingunit 215, and an end processing unit 216.

The first conforming unit 201 is in charge of interfacing between the OIprocessing unit 100 and the business logic processing unit 200. Thefirst conforming unit 201 receives an operation request message of a Biztemplate from the OI processing unit 100 and transmits the operationresult message of the Biz template to the OI processing unit 100. Inparticular, the first conforming unit 201 checks whether the operationrequest message of the Biz template recorded in the first message queue811 exists in the OI processing unit 100 and reads the operation requestmessage. Also, the first conforming unit 201 records the operationresult message of the Biz template in the fifth message queue 815 toread the operation result message of the Biz template in the OIprocessing unit 100. Accordingly, the first conforming unit 201 cantransmit the operation result message of the Biz template.

The first message analyzing and transforming unit 202 transforms theoperation request message of the Biz template transmitted through thefirst conforming unit 201 into a message format corresponding to adestination. The first message analyzing and transforming unit 202transmits the operation result message of the Biz template to the firstconforming unit 201. In particular, the first message analyzing andtransforming unit 202 receives and analyzes the operation requestmessage of the Biz template transmitted from the OI processing unit 100.Subsequently, the first message analyzing and transforming unit 202processes the operation request message of the Biz template into anobject format, which can be analyzed in the business logic processingunit 200 according to an embodiment of the present invention. When theBiz template is operated, the object is sequentially operated.

The template operating unit 203 operates the Biz template by operatingthe Biz object according to the biz logic of the Biz template. The bizlogic to be operated in the mobile communication system 13 is the logicin which a plurality of Biz objects are arranged in an order. The bizlogic is realized in a predetermined Biz template. That is, the Biztemplate is an object format in which the biz logic is realized.Therefore, the Biz template can be operated by sequentially operating aplurality of Biz objects. To be more specific, the template operatingunit 203 analyzes the received operation request message of the Biztemplate, extracts Biz objects inside the Biz template, and sequentiallyoperates each of the extracted Biz objects. The Biz template informationis loaded in a specific database. When the template operating unit 203operates the Biz template, the template operating unit 203 requests andoperates the loaded Biz template. The template operating unit 203creates cooperation with the MMDB 900 based on the session managing unit209, acquires session information of the Biz template to be operated,and operates the Biz template.

The object operating unit 204 requests a realized object of acorresponding Biz object according to the operation request of the Bizobject by the template operating unit and operates the Biz object. TheBiz object can be operated internally or by the legacy system 30 throughcooperation with the legacy cooperation processing unit 500. That is,the Biz object includes the first Biz object cooperating with the legacysystem 30 and the second Biz object performing comparing/determiningprocesses based on the operation result of the first Biz object.

The template loading unit 205 loads the Biz template and the Biz objectin a specific memory. When the template operating unit 203 requests theBiz template to be operated, the template loading unit 205 returns acorresponding Biz template from the memory. The template loading unit205 updates and deletes the Biz template loaded in the memory upon theupdating or deleting request of the Biz template loaded in the memory.

The template managing unit 206 manages the Biz template loaded in aspecific memory by the template loading unit 205 in the memory.

The second conforming unit 208 transmits the operation request messageof the Biz object to the legacy cooperation processing unit 500.Subsequently, the second conforming unit 208 receives an operationresult message of the Biz object transmitted from the legacy cooperationprocessing unit 500. The second conforming unit 208 is in charge ofinterfacing between the legacy cooperation processing unit 500 and thebusiness logic processing unit 200 according to an embodiment of thepresent invention. In particular, the second conforming unit 208 recordsthe operation request message of the Biz object in the second messagequeue 812 to read the operation request message of the Biz object in thelegacy cooperation processing unit 500. Accordingly, the secondconforming unit 208 can transmit the operation request message of theBiz object to the legacy cooperation processing unit 500. Also, thesecond conforming unit 208 checks whether the operation request messageof the Biz object recorded in the third message queue 813 exists in thelegacy cooperation processing unit 500. If the operation request messageof the Biz object exists, the second conforming unit 208 reads theresult message.

The second message analyzing and transforming unit 207 transmits theoperation request message of the Biz object to the second conformingunit 208 according to the biz logic of the Biz template upon operationrequest of the Biz template. Subsequently, the second message analyzingand transforming unit 207 transforms the operation request of the Bizobject transmitted through the second conforming unit 208 into a messageformat corresponding to a destination. In particular, the second messageanalyzing and transforming unit 207 receives and analyzes the operationrequest message of the Biz object transmitted from the legacycooperation processing unit 500. Subsequently, the second messageanalyzing and transforming unit 207 processes the operation requestmessage of the Biz object into a message, which can be analyzed in thebusiness logic processing unit 200 according to an embodiment of thepresent invention.

The business logic processing unit 200 according to an embodiment of thepresent invention provides a mechanism for processing the biz logic ofthe CP/SP system 11 at a high speed, which is a client requiring aservice of the open mobile business supporting system.

Accordingly, the open mobile business supporting system according to anembodiment of the present invention does not repeatedly process theservice logic by individually cooperating with each of the typicallegacy systems 30. The open mobile business supporting system accordingto an embodiment of the present invention can process a normal andstable service logic by managing and operating the biz logicstandardized in advance through the business logic processing unit 200.

As described above, the business logic processing unit 200 according toan embodiment of the present invention can further include the sessionmanaging unit 209, the repository managing unit 210, the log manager211, the DB cooperating unit 212, the time-out creating unit 213, theconfiguration information managing unit 214, the configurationinformation transmitting unit 215, and the end processing unit 216.

The session managing unit 209 manages session status information of theBiz template stored in the MMDB 900. In particular, the session managingunit 209 manages session information on the request of the Biz templateand session information on the operation result of the Biz template andthe Biz object. The MMDB 900 stores authentication information of theCP/SP system 11, and operation result and status information of the Biztemplate. In particular, Biz template information whose operation isrequested by the CP/SP system 11 and a unique session key allocated tothe Biz template are mapped and stored in the MMDB 900. An importantfunction of cooperating with the MMDB 900 is storing a session status, aBiz object status, session parameter information, and Biz objectparameter information. To be more specific, when a session is operatedto process a service requested from the outside or when a session statusis changed, and when a service process ends, the session status isstored. When the session starts, a session parameter is stored. Also,when an object is operated to process a service after the sessionstarts, the object status and the object parameter value are stored.

The repository managing unit 210 registers, corrects or deletes the Biztemplate information and the CP/SP information in a repository 52. Whenthe Biz template information and the CP/SP information are requested,the repository managing unit 210 reads the Biz template information andthe CP/SP information in the repository and responds to the request. Inparticular, when the business logic processing unit 200 is operated orwhen a specific Biz template is requested, the repository managing unit210 returns the Biz template information from the repository DB 1000 andreturns CP/SP authentication information from the repository DB 1000.

The log managing unit 211 manages log information on the operation andthe error of the Biz template, statistics data, and session informationon ended transaction. In particular, the log managing unit 211 createslog on the Biz template and the error outputted from the business logicprocessing unit 200. Subsequently, the log managing unit 211 stores thecreated log in an operation and management system (OMS) DB 53. Inaddition, the log managing unit 211 stores row data for statistics datain the OMS DB 53 and initializes session information on the endedtransaction.

The DB cooperating unit 212 executes a cooperating function with apre-setup database. That is, the DB cooperating unit 212 cooperates withthe pre-setup database, provides a pool function for cooperating withthe database, and executes a database update function for supporting atransaction process.

When certain conditions are met in comparison with a pre-setup time inoperation of the Biz template, the time-out creating unit 213 generatestime-out.

The configuration information managing unit 214 manages configurationinformation on the business logic processing unit 200 by providing anaccess function to an environment setup file of the business logicprocessing unit 200. In particular, when the business logic processingunit 200 according to an embodiment of the present invention changesconfiguration information, the configuration information managing unit214 reflects the change of the configuration information in real time.Accordingly, a module requiring corresponding configuration informationcan check a changed configuration information value.

The configuration information transmitting unit 215 provides aninterface with an external system. The configuration informationtransmitting unit 215 receives a configuration information checkingrequest of the business logic processing unit 200 according to anembodiment of the present invention through an external system web site54, extracts configuration information and transmits the configurationinformation to the web site. In particular, when the configurationinformation transmitting unit 215 receives the configuration informationchecking request of the business logic processing unit 200 according toan embodiment of the present invention through the external system website 54, the configuration information on-line checking module extractsa configuration information value and transmits the extractedconfiguration information value through the web site 55 realized throughthe web service providing unit 600. The developer can check theconfiguration information transmitted through the web service on aconfiguration information checking screen of the business logicprocessing unit 200. Also, the configuration information transmittingunit 215 can control a thread of the business logic processing unit 200.

The end processing unit 216 provides a function for safely ending thebusiness logic processing unit 200 according to an embodiment of thepresent invention. In particular, the end processing unit 216 creates arequest message for requesting end of the business logic processing unit200 and transmits the request message to the configuration informationtransmitting unit 215 through a specific message queue. Theconfiguration information transmitting unit 215 responds to the endrequest and ends a thread of the business logic processing unit 200.

FIG. 21 is a flowchart illustrating a business logic processing methodin the open mobile business supporting system according to an embodimentof the present invention.

Referring to FIGS. 20 and 21, the first conforming unit 201 receives theoperation request message of the Biz template transmitted of the CP/SPsystem 11 from the OI processing unit 100 in step S1500. The firstconforming unit 201 checks whether the operation request message of theBiz template recorded by the OI processing unit 100 exists in the firstmessage queue 811. When the operation request message exists, the firstconforming unit 201 reads the operation request message. Subsequently,the first conforming unit 201 loads the Biz template of the operationrequest message of the Biz template in a specific memory and analyzesthe operation request message of the Biz template in steps S1502 andS1504.

It is requested to return a corresponding Biz template loaded in thememory to operate the Biz template in S1506. The operation of thereturned Biz template starts in step S1508.

A Biz object is extracted in step S1510 according to the biz logic ofthe Biz template to operate the Biz template. The Biz template is anobject that the biz logic to be operated in the mobile communicationsystem 13 is realized. The biz logic is logic in which a plurality ofBiz objects are arranged in an order. Therefore, the operation of theBiz template is realized in step S1512 by sequentially operating Bizobjects according to the biz logic inside the Biz template whoseoperation is requested. An operation result of the sequentially operatedBiz object is received and stored in step S1514. When the operation ofthe Biz object ends, the operation of the Biz template ends. When theoperation of the Biz template finally ends in step S1516, an operationresult message of the Biz template is formed in step S1518.

As described above, the operation of the Biz template is realized bysequentially operating the internal Biz object. If the Biz object to beoperated is an I-Type, a corresponding object operation request messageis transmitted to the legacy cooperation processing unit 500 through thesecond conforming unit 208. When the operation request message of theBiz object is transmitted from the legacy cooperation processing unit500, a next Biz object is continuously operated. When a result that theBiz object is sequentially operated is stored in the MMDB 900 based onthe session managing unit 209 and the operation of the Biz templateends, an operation result message of the Biz template is formed.

The formed operation result message of the Biz template is transmittedto the OI processing unit 100 through the first conforming unit 201 instep S1520.

FIGS. 22 to 25 are flowcharts illustrating a Biz template operatingprocedure in the business logic processing unit according to anembodiment of the present invention.

FIG. 22 is a flowchart illustrating a Biz template loading and returningprocedure. Referring to FIG. 22, the template loading unit 205 of thebusiness logic processing unit 200 according to an embodiment of thepresent invention receives the operation request message of the Biztemplate from the OI processing unit 100. Otherwise, the templateloading unit 205 loads the Biz template including the Biz object in apre-setup specific memory in step S1600 when the business logicprocessing unit 200 is operated. When the template operating unit 203requests returning of the loaded Biz template to operate the Biztemplate in step S1602, the template loading unit 205 searches acorresponding Biz template in the memory in step S1604 and returns thesearched Biz template to the template operating unit 203 in step S1606.Accordingly, the template operating unit 203 operates the Biz template.

FIG. 23 is a flowchart illustrating a Biz template updating/deletingprocedure. Referring to FIG. 23, the template loading unit 205 of thebusiness logic processing unit 200 according to an embodiment of thepresent invention receives an operation request message of the Biztemplate from the OI processing unit 100. Otherwise, the templateloading unit 205 loads the Biz template in the pre-setup specific memoryin step S1700 when the business logic processing unit 200 is operated.Subsequently, when the template loading unit 205 receives the update ordelete request of the Biz template in step S1702, the template loadingunit 205 searches a corresponding Biz template in the memory and updatesor deletes the searched Biz template in steps S1704 and S1706.

FIG. 24 is a flowchart illustrating a session key extracting procedureof the Biz template in the business logic processing unit 200. Referringto FIG. 24, when the business logic processing unit 200 according to anembodiment of the present invention receives an operation requestmessage of a specific Biz template from the OI processing unit 100 instep S1800, the business logic processing unit 200 extracts a sessionkey allocated to the Biz template from the operation request message ofthe Biz template in step S1802. The OI processing unit 100 receivesstandard API input for the operation request of the Biz template fromthe CP/SP system 11, creates a session key corresponding to the Biztemplate and stores the session key with the Biz template information inthe MMDB 900. Subsequently, the business logic processing unit 200receives the session key.

As described above, the business logic processing unit 200 searches aBiz template corresponding to the transmitted session key in the MMDB900 in step S1804 and operates the searched Biz template in step S1806.

FIG. 25 is a flowchart illustrating a data processing/managing procedurein the business logic processing unit according to an embodiment of thepresent invention. Referring to FIG. 25, the business logic processingunit 200 according to an embodiment of the present invention performs amanaging process of registering, correcting, and deleting the sessioninformation on the operation request of the Biz template transmittedfrom the OI processing unit 100 and an operation result in step S1900.Subsequently, the business logic processing unit 200 creates log dataand statistics data on the operation and error of the Biz template andstores the log data and the statistics data in the OMS DB 53 in stepsS1902 and S1904. In addition, the business logic processing unit 200performs a managing process such as of registering, correcting, anddeleting the session information of the ended transaction with respectto the operating of the Biz template in step S1906.

The operations in FIGS. 22 to 25 described above can be individuallyperformed if necessary. In particular, the steps S1900 to S1906 of FIG.25 can be individually performed if necessary.

FIG. 26 is a block diagram illustrating a billing processing unit and anetwork structure of other devices to describe a billing processaccording to the operation of the Biz template in the open mobilebusiness supporting system according to an embodiment of the presentinvention. Referring to FIG. 26, the billing processing unit (BillingEngine or BE) 400 according to an embodiment of the present inventioncooperates with the business logic processing unit 200 through a messagequeue. The billing processing unit 400 cooperates with the infra channelproviding unit 300 and a pre-payment pre-subtraction billing legacysystem 420 through Transmission Control Protocol (TCP). The billingprocessing unit 400 cooperates with the billing legacy system 11 and theOMS 700 through File Transfer Protocol (FTP). The billing processingunit 400 cooperates with the repository DB 1000 through HypertextTransfer Protocol (HTTP).

Through the cooperation structure, the billing processing unit 400collects a billing log from the business logic processing unit 200 orthe infra channel providing unit 300, processes billing and transmitsthe billing log to the billing legacy system 11. Also, the billingprocessing unit 400 cooperates with the repository DB 1000 and manages abilling policy. The billing processing unit 400 cooperates with the OMS700 and transmits/receives operation and management data. In addition,the billing processing unit 400 processes a pre-payment pre-subtractionbilling process request by cooperating with the pre-paymentpre-subtraction billing legacy system 420.

FIG. 27 is a block diagram illustrating the billing processing unit.Referring to FIG. 27, the billing processing unit 400 includes a billinglog parsing unit 401, a billing policy unit 402, a billing file creatingunit 403, a billing file transmitting unit 404, and a billing policy DB405. The billing processing unit 400 according to an embodiment of thepresent invention can further include a pre-payment pre-subtractionbilling processing unit 406, a DB managing unit 407, a configurationmanaging unit 408, a log managing unit 409, a policy managing unit 410,and an OMS cooperating unit 411.

The billing log parsing unit 401 collects a billing log according to theoperation of the Biz template in the business logic processing unit 200,verifies the collected billing log, and operates a process forstandardizing the verified billing log. The billing log parsing unit 401is in charge of interfacing for billing log transmission between thebusiness logic processing unit 200 and the billing processing unit 400according to an embodiment of the present invention. In particular, thebilling log parsing unit 401 checks whether the billing log data by theoperation of the Biz template recorded in a specific message queueexists in the business logic processing unit 200. When the billing logdata exists, the billing log parsing unit 401 collects the billing log.In addition, the billing log parsing unit 401 can further include acollecting unit for collecting the content provided in the CP/SP system11 or the billing log for the user. The billing log parsing unit 401reads the billing log collected according to the Biz template, thecontent or each user on the basis of line unit. The billing log parsingunit 401 divides the billing log, verifies each billing log, transformsthe billing logs into a standardized log format and records thetransformed billing logs in the billing policy DB 405.

The billing policy DB 405 stores a plurality of billing policies andbilling data whose billing is processed. In addition, the billing policyDB 405 stores data for the billing process by the open mobile businesssupporting system according to an embodiment of the present invention.Also, the billing policy includes billing policies on a billing processfor each case, a prepayment billing process, an event billing process,and a Biz template billing process.

The billing policy unit 402 checks a billing policy to be applied to thestandardized billing log in the billing policy DB 405. Subsequently, thebilling policy unit 402 applies the checked billing policy to thebilling log and creates billing data whose billing is processed. Thebilling policy unit 402 includes an interface with the infra channelproviding unit 300, which cooperates with the legacy system 30 insidethe mobile communication system 13. Also, the billing policy unit 402can further include an authenticating unit (not shown) for performing auser authentication process corresponding to the billing log.

As shown in FIG. 28, the billing policy unit 402 includes a log receiver41, a log filter 42 and a billing processor 43.

The log receiver 41 receives the billing log standardized in the billinglog parsing unit 401 and performs a billing preprocess on anon-processed billing log. The log filter 42 filters a duplicatedbilling log of the collected billing log and transmits each of thefiltered billing log to a billing process table for the billing process.The billing processor 43 applies each billing policy to each billing logtransmitted to the billing process table, operates a billing process andcreates billing data.

The billing file creating unit 403 creates a billing file MDR to betransmitted to the billing legacy system 11 of the mobile communicationsystem 13 based on the billing data whose billing is processed. Thebilling file MDR is a file format, which is a readable file for thebilling process in the billing legacy system 11. In particular, thebilling file creating unit 403 collects the billing data whose billingis processed and creates the billing file MDR in conformity to an FTPcommunications protocol.

The billing file transmitting unit 404 transmits the created billingfile MDR to the billing legacy system 11. The billing file transmittingunit 404 may transmit the billing file MDR to the billing legacy system11 based on the FTP.

The billing processing unit 400 according to an embodiment of thepresent invention can realize real-time billing process, exact billingprocess and transmission according to the operation of the biz logic ofthe CP/SP system 11, which is a client requiring a service of the openmobile business supporting system. Accordingly, it is not required toprocess billing by cooperating with each module to support diverse kindsof billing patterns in a typical method. Since the billing processingunit 400 collects a billing log and applies a corresponding billingpolicy, it is possible to minimize cooperation of each module in thebilling process.

As described above, the billing processing unit 400 of FIG. 27 canfurther include the pre-payment pre-subtraction billing processing unit406, the DB managing unit 407, the configuration managing unit 408, thelog managing unit 409, the policy managing unit 410, and the OMScooperating unit 411.

The pre-payment pre-subtraction billing processing unit 406 receives apre-payment pre-subtraction billing process request of a specificbilling log from the business logic processing unit 100. Subsequently,the pre-payment pre-subtraction billing processing unit 406 requests apre-payment pre-subtraction billing process to the pre-paymentpre-subtraction billing legacy system 420 for performing the pre-paymentpre-subtraction billing process. The pre-payment pre-subtraction billingprocessing unit 406 receives and returns a result. The billing logparsing unit 401 verifies a specific billing log to which thepre-payment pre-subtraction billing process is requested. Also, thebilling log parsing unit 401 performs a standardization process on thebilling log transmitted from the pre-payment pre-subtraction billingprocessing unit 406. The pre-payment pre-subtraction billing processingunit 406 includes an interface for cooperating with the business logicprocessing unit 200 and the pre-payment pre-subtraction billing legacysystem 420. In particular, the pre-payment pre-subtraction billingprocessing unit 406 cooperates with the pre-payment pre-subtractionbilling legacy system 420 based on the TCP.

The DB managing unit 407 cooperates with a pre-setup database andperforms an access process from the billing process device to thedatabase, and access management and release processes.

The configuration managing unit 408 provides an access function to anenvironment setup file of the billing processing unit 400 and managesconfiguration information on the billing processing unit 400. Inparticular, the configuration managing unit 408 checks and manages asetup file commonly used in the billing processing unit 400 and a uniquesetup file.

The log managing unit 409 manages a common log format of the billingprocessing unit 400. Also, the log managing unit 409 manages creationand record of a system log, and a processed log file.

The policy managing unit 410 registers, corrects, or deletes a billingpolicy including a billing information synchronization process on theBiz template and the content, an event management process, a billingverification process, a billing policy synchronization process, backupof a billing policy in a pre-set up repository 52. When the billingpolicy is requested, the policy managing unit 410 reads the billingpolicy in the repository 52 and responds to the request.

The OMS cooperating unit 411 collects, transmits and manages data foroperating and managing the billing processing unit 400 managed in theOMS 700 by cooperating with the OMS 700.

FIG. 29 is a flowchart illustrating a method of billing processaccording to an embodiment of the present invention. Hereinafter, abilling process of a billing processing unit 400 will be described withreference the FIG. 29.

The billing log parsing unit 401 collects billing log according to thebiz template perform at the business logic processing unit 200 in stepS2300. The billing log parsing unit 401 collects billing log throughcooperating with the business logic processing unit 200 and a messagequeue. That is, the billing log parsing unit 401 determines whether thebilling log data is recorded in a predetermined message queue by thebusiness logic processing unit 200. If the billing log data is presentin the message queue, the billing log data is read. In the step S2300,billing log for content provided from the CP/SP system 11 or a user canbe collected.

Then, it verifies the validity of the collected billing log in stepS2302. In order to verify the validity, the billing log is classified bya type thereof and the verification is performed. Then, the validbilling log is standardized in step S2304. Billing data is created byapplying a predetermined billing policy to the standardized billing login step S2306 and S2308. FIG. 30 shows a procedure of applying thebilling policy.

Referring to FIG. 30, when the standardized billing log is received instep S2400, a connection to a billing policy DB 405 is requested in stepS2402. If the billing policy DB 405 is successfully connected in stepS2404, a billing policy to apply to the collected billing log isinquired from the billing policy DB 405 in step S2406. No billing policyis present in the billing policy DB in step S2408, an error log isrecorded in step S2416. If the proper billing policy is resent, billingdata is created by applying the billing policy to the collected billinglog in steps S2410 and S2412. Then, the connected to the billing policyDB 405 is terminated in step S2414.

Afterward, a billing file MDR is created by collecting the billing datato transmit the billing file MDR to the billing legacy system 30 of themobile communication system 13 in steps S2310 and S2312. The billingfile MDR has a format that can be recognized by the billing legacysystem. The billing file is created to be suitable to FTP. Then, thecreated billing file (MDR) is transmitted to the billing legacy system11 using FTP in step S2314.

The billing processing unit 400 according to an embodiment of thepresent invention performs a prepay and pre-subtracting billing processcorresponding to the request by cooperating with the pre-paymentpre-subtraction billing legacy system 420.

FIG. 31 is a flowchart illustrating a prepay and pre-subtracting processperformed in the billing processing unit 400. Referring to FIG. 31,after step S2300, the billing processing unit 400 receives a request ofperforming a prepay and pre-subtracting billing process from thebusiness logic processing unit 200 in step S2500. Then, the validity ofbilling log is verified in step S2502. If the billing log is not validin step S2504, an error log is recorded in step S2506. If the billinglog is valid in step S2504, it requests to connect to the pre-paymentpre-subtraction billing legacy system 420 in step S2508.

If the connection is failed in step S2510, an error log is created andrecorded in step S2506. If the connection is successfully established instep S2510, the prepay and pre-subtracting process is requested and theresult thereof is returned in steps S2512 and S2514. The connection tothe pre-payment pre-subtraction billing legacy system 11 is terminatedin step S2516, the prepay and pre-subtracting processed billing log isstandardized, and a billing process is performed in steps S2518 andS2520.

FIG. 32 is a flowchart illustrating a procedure of processing andmanaging billing data in a billing processing unit 32 according to anexemplary embodiment of the present invention. Referring to FIG. 32, abilling policy is registered, modified, and deleted to/from apredetermined repository DB 1000 in step S2600. When the billing policyis required for the billing process in step S2602, the billing policy isreturned in step S2604. Also, common log format, system log creation,and record, and processed log file management are performed in stepS2606. Also, common setup file and a unique setup file inquiry areperformed in step S2608. Then, data is collected and managed foroperating and managing in step S2610. Moreover, log data and statisticdata for performing biz template and error thereof are generated andstored in the OMS 700 in steps S2612 and S2614). Each process in FIG. 32can be performed independently according to needs.

FIG. 33 is a block diagram illustrating the infra channel providing unit300. Referring to FIG. 33, the infra channel providing unit 300 includesan API processing unit 301, a gateway unit 302, an on-line inquiry unit303, and a log uploading unit 304. The API processing unit 301 providesan execution parameter of a biz object for a legacy system 30,processing input and output parameters for executing a biz object,transfers the input parameter to the gateway unit 302, and transfers theresults, the output parameter, to the legacy system 30 that performs therequest of the biz object. The gateway unit 302 performs the requestedbiz object using the input parameter transferred from the API processingunit 301, thereby transferring a cooperation request to a legacycooperation processing unit 500. The gateway unit 302 also request acooperation request to the legacy cooperation processing unit 500,receives the result thereof, and transfers the received result to theAPI processing unit 301. Furthermore, the on-line inquiry unit 303provides the environmental setup value of the gateway unit 302 to a webservice providing unit 600. The log uploading unit 304 provides the logof the infra channel providing unit 300 to an OMS 700, regularly.

The gateway unit 302 includes an interface unit 305, a message relayunit 306, a MQ managing unit 307, a configuration managing unit 308, alog managing unit 309, an OMS managing unit 310, and a DB managing unit311. The interface unit 305 provides an input/output interface to theAPI processing unit 301. The interface unit 305 includes atransmitting/receiving module 305 a for receiving a biz object requestfrom the API processing unit 301 and transferring a processing result tothe API processing unit 301, an authentication managing module 305 b forprocessing a user right authentication of a legacy system 30 accessingthe API processing unit 301, a session managing module 305 c forcreating and managing a unique session key for an authenticated requestfrom the authentication managing module 305 b, a thread managing module305 d for supporting a multi-thread process to process the authenticatedrequest from the authentication managing module 305 b. The message relayunit 306 relays a message for requesting. The message relay unit 306includes a request relay module 306 a for analyzing an API requestedfrom the interface unit 305 and relaying a message from a messagetransferring unit 800, and a message composing module 306 b for parsinga parameter transferred from the API processing unit 301 to a format totransfer to the message transferring unit 800. The MQ managing unit 307supports a MQ cooperation protocol. The first transmission module 307 atransmits a message to the legacy system 30 by cooperating with thelegacy cooperation processing unit 500 through the message transferringunit 800. The second transmission module 307 b transfers a message tothe billing processing unit through the message transferring unit 800for billing log. The receiving module 307 c receives a message from thelegacy cooperation processing unit 500 and the billing processing unit400 through the message transferring unit 800. The configurationmanaging unit 308 manages environmental setting such as a log generationperiod and a system environment of the infra channel providing unit 300.The log managing unit 309 creates a log file of the infra channelproviding unit 300, and creates a monitoring data log to be transmittedto the OMS 700. The OMS managing unit 310 transmits monitoring datastored as a file format by the log managing unit 309 to the OMS 700 at aregular period. The DB managing unit 311 records or reads data byperforming access and transaction to the MMDB 900.

The log managing unit 309 does not directly access the OMS 700 forsystem performance.

FIG. 34 is a block diagram illustrating a cooperating structure of theinfra channel providing unit 300. Referring to FIG. 34, the APIprocessing unit 301 is connected to the legacy system 30 through aTCP/IP protocol. The infra channel providing unit 300 exchanges amessage with a legacy cooperating unit 43 and the billing processingunit 400 through the message transferring unit 800 using the MQcooperating protocol. The infra channel providing unit 300 and the OMS70 are connected through an ODBC and a FTP. The infra channel providingunit 300 is connected to the web service unit 48 and the ODBC.

In order to improve a processing speed, a TCP/IP socket protocol is usedbetween the API processing unit 301 and the gateway unit 302. A messagequeue is used to transfer a message between the gateway unit 302 and theother constitutional elements of the open mobile business supportingsystem such as the legacy cooperation processing unit 500 and thebilling processing unit 400. Furthermore, it does not require additionalcooperation interface with the legacy system 30.

The API processing unit 301 supports various platforms such as NT, SUN,IBM, AIX, and HP-UX, and can be embodied by development languages suchas C/C++ and Java, and provides an API mapped to a biz object in a 1:1manner.

According to the described configuration, the infra channel providingunit 300 builds an infra integrated structure of a standardizedcommunication channel to the legacy system 30, supports variousplatforms and development languages to allow related services to be usedon Web, guarantees the connection reliability between a synchronousTCP/IP socket scheme and an asynchronous MQ communication scheme, andperform quick function of a biz object unit.

The operations of the infra channel providing unit 300 will be describedwith reference to FIG. 35 and FIG. 36, hereinafter.

Referring to FIG. 35, the API processing unit 301 provides a commonlibrary type API to the legacy system 30. That is, the API processingunit 310 takes a charge of a client part in socket communication. When apredetermined biz object is selected from a predetermined legacy system30 in step S2901, it determines whether the biz object is present or notin step S2902. If not, an error code is transmitted to the correspondinglegacy system 30 in step S2903. If the biz object is present, the socketcommunication with the gateway unit 302 is prepared in step S2904.

If an access is not successful after accessing the gateway unit 2092through the socket communication in step S702, re-access is performedand it determines whether the re-access is successful or not. If not, anerror code is transmitted to a legacy system 30 that request a bizobject at S2909.

On the contrary, if the access to the gateway unit 302 through thesocket communication is successful, it transmits an objectID, an APIauthentication key objectAuthKey, an IP address of infra channelproviding unit, a port number (portNo), an input parameter set (inSet),and an output parameter set of a result of executing a biz object inS2910.

It waits to receive the execution result from for the gateway unit 302in step S2911.

If the result is received from the gateway unit 302, the received resultvalue is returned to the legacy system 30 that request the correspondingbiz object to execute in step S2913.

Hereinafter, a procedure of executing a biz object will be describedwith referring to FIG. 36, if the legacy system 30 request a biz objectto execute in step S3001, parameters for executing the biz object aretransmitted to the infra channel providing unit 300 in step S3002.

As described above with reference to FIG. 35, the API processing unit301 of the infra channel providing unit 300 receives the parameters suchas an objectID, an objectAuthKey, an ipAddr, a portNo, an in Set, and anoutset to the gateway unit 302 through socket communication in stepS3003.

The authentication managing module 305 b of the gateway unit 302authenticates whether a corresponding legacy system 30 has an API usageright or not based on the objectAuthKey among the parameters in stepS3004. If the legacy system does not have the API usage right in stepS3005, it transmits a message of authentication failure to the legacysystem 30 and the legacy system 30 receives the message in steps S3006and S3007.

On the contrary, if the legacy system has the API usage right, a log iscreated in step S3008, the session managing module 305 c creates aunique session key for the request in step S3009, and the threadmanaging module 305 d creates threads for performing the request in stepS3010.

When the message composing module 306 b receives the parameters throughthe created thread, the message composing module 306 b composes arequest message to transmit to the message transferring unit 800 byparsing the received parameters in step S3012. The first transmissionmodule 307 a of the MQ managing unit 307 recodes the created requestmessage in an assigned message queue for the legacy cooperationprocessing unit to receive the generated request message in steps S3013and S3014.

A corresponding legacy cooperation processing unit 500 reads the messagerecorded in the message transferring unit 800, processes a biz objectaccording to the request message, and records the result thereof into amessage queen of the message transferring unit 800 so that the infrachannel providing unit 300 receives the result thereof in steps S3015 toS3017.

The receiving module 307 c of the infra channel providing unit 300receives the result message in step S818. Afterward, the message relayunit 306 analyzes the received messages, detects the execution result ofthe biz object, and transmits the result thereof to the legacy system 30that requests the execution of the biz object through the API processingunit 301 in step S3020. At the ending time of executing the biz object,a log is stored in step S3021.

As described above, the infra channel providing unit according to anembodiment of the present invention provides a unified cooperation rulebetween the legacy systems 30 by relaying the use of the legacy system30 for a biz object that embodies a unit function per a legacy system30.

As the billing process for a related biz object in the infra channelproviding unit 300, the session managing module 305 c analyzes thesession information of the currently executing biz object, determineswhether the biz object is successfully processed or not, creates billingdata if it is successfully processed, composes a billing message throughthe message relay unit 306 b, and transmits the billing message to themessage transferring unit 800 through the second transmission module 307b of the MQ managing unit 307 so that the billing processing unit 400receives the transmitted billing message. Then, the session managingmodule 305 c receives a result message of processing the billing datafrom the billing processing unit 400 using the receiving module 307 cand stores the received result message in a billing data log. Therefore,in the present embodiment, proper billing data is collected andprocessed whenever a biz object is executed.

Furthermore, the log managing unit 309 of the infra channel providingunit 300 creates a log file for the infra channel providing unit 300 anda monitoring data log to be transmitted to the OMS 700. That is, the logmanaging unit 309 selects files to send from the created log files or areport log DB. Then, the log uploading unit 304 transmits the selectedlog files to the OMS 700 through a FTP by regularly requesting to theOMS 700 for FTP access. When the log uploading unit 304 receives aresponse for receiving a log file from the OMS 700, the log uploadingunit 304 determines that the corresponding log file is successfullytransmitted, releases the FTP access, and deletes the transmitted logfiles. The infra channel providing unit 300 helps the OMS 700 to managethe log information of the infra channel providing unit by regularlytransmitting the log file and the report log file of the system to theOMS 700.

Moreover, the log managing unit 309 creates debugging information,malfunctioning information, system operation information generated fromeach module of the infra channel providing unit 300 as logs and storesthe created logs in a system log file. The log managing unit 309 loads alog environment file, reflects modified setup values to the environmentfile if the environmental setup values are modified, or sustains theenvironment file as it is if the environmental setup values are notmodified. Then, the log managing unit 309 checks a rotate period. If therotation is required, the log managing unit rotates the log file tocreate new log file for debugging information, malfunction information,and system operation information of the infra channel providing unit 300to create the new log file, creates logs of each level based on the newlog file, and stores the created logs and files at the system log file.

The configuration information modified by a manager is updated tocontrol threads in the infra channel providing unit 300 in real time. Inorder to update, the configuration managing unit 308 of the infrachannel providing unit 300 loads a configuration file of a currentlysetup system, determines whether the configuration information ismodified or not, and applies the modified configuration to the infrachannel providing unit 300 in real time if the modification is made.Furthermore, the configuration managing unit 308 determines whether atread environment is modified or not, the configuration managing unit308 performs thread control if the thread environment is modified.

When the on-line inquiry unit 303 receives an inquiry request messagefrom the web service providing unit 600, the on-line inquiry unit 303loads a configuration file managed by the configuration managing unit308, parses inquiry lists, composes a result message, and the resultmessage to the web service providing unit 600.

The OMS managing unit 60 of the infra channel providing unit 300regularly loads a log file generated from the log managing unit 309,extracts access information, directly accesses the DB of the OMS 700,and transmits the monitoring statistical data to the OMS 700.

FIG. 37 is a block diagram illustrating a structure of a legacycooperation processing unit 500 in a mobile business supporting systemaccording to an embodiment of the present invention. The legacycooperation processing unit 500 includes a common managing unit 510 anda legacy cooperating interface unit 520.

The common managing unit 510 receives a cooperation request forperforming the biz template from the business logic processing unit 200and returns the result of processing the received request to thebusiness logic processing unit 200. The common managing unit 510 alsomanages the system environment and the log thereof. The cooperationrequest of legacy system 30 is that the legacy cooperation processingunit 500 requests the legacy system 30 to perform a biz object so as toperform a biz template at the business logic processing unit 200. Inresponse to the cooperation request, the legacy system 30 performsrelated services such as SMS transmission, MMS transmission, positiondata inquiry, and user data inquiry, and provides the result thereofsuch as message transmission completion, position data, or user data.

The legacy cooperation interface unit 520 includes, for example, an SMSinterface 521, an MMS interface 522, an LBS interface 523, and anauthentication interface 524. The legacy cooperation interface unit 520further includes a push interface 525 and a download interface 526.According to the type, function and system environment of business logto be supported, various legacy cooperation interfaces can be added forcooperating with the legacy system 30. The legacy cooperation interfaceunit 520 relays the cooperation request for performing the biz templatefrom the legacy system 30 and returns the result thereof to the legacysystem 30.

The SMS interface 521 cooperates with an MASS that is located in thelegacy system 30 and performs a wireless Internet SMS transmissionservice of a wireless communication system. The SMS interface 521requests the MASS to transmit an SMS message, receives information aboutthe result thereof such as message transmission completion or messageread, and transforms the received information to a standard interfacetype.

The MMS interface 522 cooperates with an MMSC that is located in thelegacy system 30 and performs an MMS service of a wireless communicationsystem. The SMS interface 521 requests the MMSC to transmit an MMSmessage, receives information about the result thereof such as messagetransmission completion or message read, and transforms the receivedinformation to a standard interface type.

The LBS interface 523 cooperates with an LBSP that is located in thelegacy system 30 and performs a position based service of a wirelesscommunication system. The LBS interface 523 transfers a position relatedrequest such as position information inquiry to the corresponding LBSP,and transforms the result of processing the position related request toa standard interface type.

The authentication interface 524 cooperates with an authenticationsystem that is located in the legacy system 30 and authenticates awireless communication system. The authentication interface 524 requestsa corresponding authentication system to perform an authenticationprocess and transforms the result of performing the authenticationprocess to a standard interface type.

The push interface 525 performs a push type message transmission serviceby cooperating with the MASS 32 and the CBCS 35 of a legacy system 30,and transforms the result thereof to a standard interface type.

The download interface 526 performs a download service of image, music,and text by cooperating with a download platform of the legacy system30, and transforms the result thereof to the standard interface.

The legacy cooperation interface unit 520 is described to include theseinterfaces in the present embodiment. However, the interfaces of thelegacy cooperation processing unit 500 can vary according to the legacysystem 30 and the related biz objects.

Hereinafter, the operations of the legacy cooperation processing unit500 will be described. At first, when the common managing unit 510receives a request message of the legacy system 30, which is requiredfor performing the biz template, from the business logic processing unit200 through the message transferring unit 800 formed as a message queue,the common managing unit 510 transfers the request to the legacycooperation interface unit 520. Then, the legacy cooperation interfaceunit 520 transforms the request to a format proper to the legacy systemthrough protocol transformation and transmits the transformed request toa corresponding legacy system 30. Afterward, the legacy system 30performs predetermined operations related to the received request suchas SMS transmission, MMS transmission, position data inquiry, or userdata inquiry, and transmits the result thereof such as messagetransmission completion, message read, position data, or user data tothe legacy cooperation interface unit 520. The legacy cooperationinterface unit 520 transforms the received results to a standard outputmessage format of a legacy system cooperation result, and transfers thetransformed output message to the common managing unit 510. The commonmanaging unit 510 returns the processing result to the business logicprocessing unit 200 or to the infra channel providing unit 300 throughthe message transferring unit 800.

FIG. 38 is a block diagram illustrating the common managing unit 510 inthe legacy cooperation processing unit 500. Referring to FIG. 39, thecommon managing unit 510 includes an MQ managing unit 511, aconfiguration managing unit 512, a log managing unit 514, a log uploader516, and a DB interface 517.

The MQ managing unit 511 includes an MQ receiver 511 a and an MQtransmitter 511 b, and manages a transmission operation and a receivingoperation of messages to/from the business logic processing unit 200 andthe infra channel providing unit 300. In one embodiment, the MQ managingunit 511 has a function to check the data validity. The MQ receiver 511a is a module for processing messages received from the messagetransferring unit 800, that is, a message queue. The MQ receiver 511 astores request information from the business logic processing unit 200or the infra channel providing unit 300 through the message transferringunit 800 into a database or transforms the received message to a legacyformat. The MQ transmitter 511 b transmits the processing result of thelegacy system 30 to the business logic processing unit 200 or the infrachannel providing unit 300 through the message transferring unit 800,and supports a protocol process for cooperating with a message queue.

The configuration managing unit 512 manages a system environment orenvironmental setups such as a log create cycle for each constitutionalelement of the legacy cooperation processing unit 500, and stores thestate information of the system environment as a configuration file 513.The configuration managing unit 512 manages the configuration files toreflect the changes thereof into the configuration files throughre-driving the legacy cooperation processing unit 500 when theconfiguration file is modified, or to instantly reflect in real timewithout re-driving. That is, the configuration managing unit 512 manageschanges of each constitutional element for the legacy cooperationprocessing unit 500 using the configuration file 513 and sets up anexecution environment by reading the configuration file 513 in real timewhen the system is driven. In the configuration information management,a configuration data value is inquired by receiving a KEY value from aprogram or a module requesting the configuration information. Theconfiguration information is frequently modified, deleted, or inputtedby directly accessing the configuration file 513. When the configurationinformation is modified, deleted, or inputted, the configurationmanaging unit 512 reflects the real-time modified configurationinformation to the current legacy cooperation processing unit 500, andprovides the reflected configuration information to programs andmodules.

The log managing unit 514 generalizes a log format of each log level ineach constitutional module of the legacy cooperation processing unit500, and creates a system log based on a log format and a log levelassigned from each constitutional module. Such log information is storedin the log file 515. The log creation is to create logs for debugginginformation, malfunctioning information, and system operationinformation, which are generated from each module, and stores thecreated log into the system log file 515. The log level can be setupaccording to the system environment. For example, various log levelssuch as an error level, an information providing level, a warning level,or a debug level can be setup according to the related environment. Whenthe log is requested, the log is created according to the related loglevels set up according to the related environment.

The log managing unit 514 receive log data transmitted from eachconstitutional module of the legacy cooperation processing unit 500,transforms the received log data to a format suitable to output it tothe log file 515, opens a log file 515 according to each constitutionalmodule and conditions thereof; and records the log data to the openedlog file 151.

The log uploader 516 regularly searches the system log of the legacycooperation processing unit 500 and uploads the searched system log tothe OMS 700 using FTP. The log uploader 516 regularly searches the logfile 515 of the legacy cooperation processing unit 500, requests the OMS700 to FTP access, and uploads the log file 515 if it successfullyaccesses.

The DB interface 517 provides an interface to the legacy cooperationinterface unit 520 and the legacy integrated DB server 530. The legacyintegrated DB server 530 stores and manages session information aboutmessage transmission state, transmission result for asynchronousmessaging process when the legacy system 30 transmits or receives amessage.

FIG. 39 is a block diagram illustrating an SMS interface 521 in a legacycooperation processing unit 500.

Referring to FIG. 39, the SMS interface 521 includes an SMS servicelistener 521-1, a session manager 521-2, an MASS request manager 521-3,an MASS response manager 521-4, and an SMS response manager 521-5.

The SMS service listener 521-1 receives the legacy system cooperationrequest transferred from the MQ receiver 511 a of the MQ managing unit511, and registers the requests in the legacy integrated DB server 530.Herein, the legacy system cooperation request is a request ofcooperating for the MASS 32 which is a wireless Internet SMStransmission system.

The SMS session manager 521-2 receives an SMS transmission request ofthe MQ receiver 511 a from the legacy integrated DB server 530, andproves the received request to the MASS request manager 521-3. The SMSsession manager 521-2 requests the session states such as servicerequest or the result thereof to the legacy integrated DB server 530.

The MASS request manager 521-3 also requests the MASS 32 to perform anSMS messaging service.

The MASS response manager 521-4 receives a processing result such asmessage transmission completed or message read from the MASS 32 afterthe MASS 32 transmit the SMS message.

The SMS response message 521-5 receives an MASS cooperation resultinformation from the MASS response manager 521-4 and registers thereceived information at the legacy integrated DB server 530. Then, theSMS service listener 521-1 obtains the results from the legacyintegrated DB server 530, and transfers the obtained result to the MQtransmitter 511 b of the MQ managing unit 511. The MQ transmitter 511 bprovides the request processing result of the business logic processingunit 200 and the infra channel providing unit 300 by recording therequest processing result to an assigned message queue.

FIG. 40 is a block diagram illustrating an MMS interface 522 in a legacycooperation processing unit 500 according to an embodiment of thepresent invention.

Referring to FIG. 40, the MMS interface 522 includes an MMS ServiceListener 522-1, a protocol stack module 522-2, a file data manager522-3, a session manager 522-4, an MM7 interface 522-5, an MMS reporter522-7, and a legacy interface 522-6.

The MMS service listener 522-1 receives a legacy system cooperationrequest from the MQ receiver 511 a of the MQ managing unit 511 andresisters the received request at the legacy integrated DB server 530.The cooperation request from the business logic processing unit 200 toprocess an MMS message is belonging to a cooperation request for an MMSC33 that takes a charge of transmitting an MMS message.

The protocol stack module 522-2 processes protocols, such as HTTP, SMTP,MIME, DIME, and SOAP, for transforming a message to a predeterminedformat to cooperate with the MMSC.

The file data manager 522-3 receives reference data including the MMSCcooperation request message, and performs a function to receiving an MMSmessage by cooperating with a file server (not shown) having the realMMS message content.

The session manager 522-4 receives an MMSC cooperation request message,which is transferred from the MQ receiver 511 a, from the legacyintegrated DB server 530, and relays the received MMC cooperationrequest message to the MM7 interface 522-5.

The MM7 interface 522-5 transforms the MMSC cooperation request messagetransferred from the session manager 522-4 to a format suitable to MM7that is an MMSC cooperation protocol, and transmits it the legacyinterface 522-6.

The legacy interface 522-6 requests an MMS messaging service such as MMSmessage transmission by cooperating with the MMSC 33 according to thelegacy system cooperation request, and receives the service processingresult from the MMSC.

The MMS reporter 522-7 receives a cooperation processing result from theMMSC 33 through the legacy interface 522-6, and provides the receivedcooperation processing result to the legacy integrated DB server 530through the DB interface 517. As described above, The MMS reporter 522-7stores the cooperation processing result to the legacy integrated DBserver 530, and the MMS service listener 147-1 provides the cooperationprocessing result to the business logic processing unit 200 or the infrachannel providing unit 300 through the MQ managing unit 511. Forexample, when the business logic processing unit 200 requests the MMSmessage transmission, the MMS reporter 522-7 receives information aboutwhether a real phone user receives the MMS message from the legacysystem 30 or not, stores information in the legacy integrated DB server530, and manages the stored information. By allowing such information tobe transmitted to the business logic processing unit 200, the businesslogic processing unit 200 is enabled to charge a fee for transmitting acorresponding MMS message. That is, the MMS reporter 522-7 receivesinformation about whether a MMS message is received or not from the MMSCthrough a SOAP type message, extracts required data from the SOAP typemessage by analyzing the SOAP type message, and determines whether theextracted data is valid or not, thereby finely analyzing the reportinformation. Also, the MMS reporter 522-7 transfers the informationwhether the report information is received or not to the MMSC, andupdates the report information to the database. Afterward, the MMSreporter 522-7 transforms the report result information to the MQ typemessage in order to transmit the report result information to thebusiness logic processing unit 200 through the message relay unit 30.Furthermore, the MMS reporter 522-7 registers the received resultreceived from the MMSC at the legacy integrated DB server 530. The MMSservice listener 522-1 obtains the service result from the legacyintegrated DB server 530, and transfers the obtained service result tothe MQ transmitter 511 b in the MQ managing unit 511, thereby allowingthe MMSC cooperation result to be provided to the business logicprocessing unit 200.

As shown in FIG. 41, a biz template for the MMS messaging serviceincludes a biz object {circle around (1)} for inquiring I-type userinformation, a biz object {circle around (2)}, for checking P-type userinformation, a biz object {circle around (3)} for checking whether aP-type terminal is supported or not, and a biz object {circle around(4)} for transmitting an I-type MMS.

Therefore, when the business logic processing unit 200 receives arequest of performing an MMS message transmission biz template, thebusiness logic processing unit 200 inquires user information andauthenticates the request by requesting authentication related legacysystems to be cooperated. The business logic processing unit 200 checksthe user information included in the processing result thereof. If theuser information is not proper, the business logic processing unit 200returns authenticating failure as the processing result. If the userinformation is proper, the business logic processing unit 200 requests alegacy system for managing terminals to be cooperated to check theterminal information. Then, the business logic processing unit 200transmits corresponding message by requesting the MMSC to cooperate.

FIG. 42 is a block diagram illustrating an LBS interface of a legacycooperation processing unit 500 according to an embodiment of thepresent invention. Referring to FIG. 42, the LBS interface 523 includesan LBS service listener 523-1, an extensible markup language (XML)generator 523-2, a legacy interface 523-3, and an XML parser 523-4.

When the business logic processing unit 200 requests an LBSP 34 tocooperate for performing a position information inquiry businesstemplate in order to perform a business logic related to a positionbased service, the LBS service listener 523-1 receives a legacy systemcooperation request from the business logic processing unit 200 throughthe MQ receiver 511 a of the MQ managing unit 511, and transmits theprocessing result of the cooperation request to the business logicprocessing unit 200 through the MQ transmitter 511 b. The legacy systemcooperation request transferred from the business logic processing unit200 belongs to a cooperation request for an LBSP that processes theinformation of location-based services (LBS).

FIG. 43 is a diagram illustrating a biz template for inquiring positioninformation, as an example of a location based service (LBS) related biztemplate. Referring to FIG. 43, the biz template is for inquiring aposition of a predetermined portable phone. The biz template includes abiz object {circle around (1)} for inquiring I-type user information, abiz object {circle around (2)} for checking P-type user information, anda biz object {circle around (3)} for inquiring an I-type LBS position.

When an LBS biz template is performed, the business logic processingunit 200 inquires the user information by requesting a user relatedlegacy system to cooperate. Then, the business logic processing unit 200determines whether the service can be provided or not by checking theuser information using the inquired information. If it is impossible toprovide, the business logic processing unit 200 returns a failuremessage as the processing result. If it is possible, the business logicprocessing unit 200 requests the LBSP 34 to cooperate through the legacycooperation processing unit 500, thereby inquiring the positioninformation thereof.

Continuously, the XML generator 523-2 of FIG. 42 receives the legacysystem cooperation request message from the business logic processingunit 200 through the MQ managing unit 511, and transforms the receivedmessage to an XML sentence to be suitable to the LBSP 34.

The legacy interface 523-3 requests position information inquiry bycooperating with the LBSP 34 that processing LBS information fortracking, and receives the result of the position inquiry.

The XML parser 523-4 analyzes the XML processing result from the legacyinterface 523-3, and the interpreting result to the LBS service listener523-1.

Then, the LBS service listener 523-1 transfers the result of inquiringthe position thereof to the MQ transmitter 131-2 of the MQ manager 131so as to transfer the position inquiry result to the business logicprocessing unit 200.

FIG. 44 is a flowchart illustrating a method of performing an LBSrelated service using a legacy cooperation processing unit 500 having anLBS interface 523 according to an embodiment of the present invention.

Referring to FIG. 44, the legacy cooperation processing unit 26 havingthe LBS interface 523 receives a request to cooperate with the LBSP 34of the legacy system 30 from the business logic processing unit 200 forposition inquiry and messages related to request of setting upenvironment through a message queue of the message transferring unit 800in step S3801. Then, the legacy cooperation processing unit 26 inspectsthe validity of the received messages such as the received LBSPcooperation request and the environment setting up message in stepS3802.

If the received messages are valid in the step S3803, the parameters ofthe LBS service requesting message are stored in assigned buffersaccording to corresponding request types in step S3804.

Then, using an XML generator 523-2, an XML file is created based on thecontent in the assigned buffer in step S3805.

Afterward, the generation of the XML file is determined in step S3806.If the XML file is normally created, the TCP/IP connection to the LBSPis established in step S3807.

The TCP/IP connected to the LBSP from the legacy system 800 issuccessfully established in step S3808, the created XML message to theLBSP in step S3809.

Afterward, the current session is sustained until a response for LBSPcooperating request, that is, a position inquiry result message havingan XML format, from the LBSP. In step S3810, the XML type responsemessage is received.

Then, the format of the received XML response message from the LBSP ischecked. The checked XML message is parsed using the XML parser 523-4 inorder to use the received XML response message in the business logicprocessing unit 200 in step S3811.

When the parsing ends in the step S3812, the parsed message istransformed to a message format to transmit it the business logicprocessing unit 200, and the transformed message is transmitted to thebusiness logic processing unit 200 through message queues of the messagetransferring unit 800. That is, the position inquiry result istransmitted to the business logic processing unit 200 in step S1613, anda related result is recorded at the log file 515 in step S3814. In stepsS3803, S3806, S3808, and S3812, log information according to thedetermination is recorded in the log file 515 in step S3814.

FIG. 45 is a block diagram illustrating a push interface according to anembodiment of the present invention.

Referring to FIG. 45, the push interface 525 according to an embodimentof the present invention includes a push service setup manager 525-1, acontent transmitter 525-2, and a legacy interface 525-3. The pushservice setup manager 525-1 manages connection information received fromthe CP/SP system 21 through the common managing unit 510 and serviceregistration/release information form a mobile communication terminal14. The content transmitter 525-2 manages content and messages receivedthrough the MQ managing unit 511 and controls a transmission scheme ofthe content and a transmission time. The legacy interface 525-3transmits a message to a legacy system performing an SMS service, anMASS 32, a legacy system performing a cell broadcasting service, or theCBSC 35 through a push method, and receives the processing resultthereof.

The push interface 525 cooperates with a legacy system. That is, thepush interface 525 transmits a push type message to a plurality ofmobile communication terminals by cooperating with a cell broadcastingservice center (CBSC) that transmits a message to a mobile communicationterminal within a predetermined cell or with a short message servicecenter (SMSC) that transmits a short message.

In generally, a billing process for the push service is performed as amonthly flat rate. Therefore, billing data for the push service iscreated, and the billing processing unit 400 of the open mobile businesssupporting system processes the created billing data.

When a user access a wireless communication system using a mobilecommunication terminal 14 having a popup application program or a tickerprogram and requests registration or termination of popup services forstock information and weather information or ticker services, the pushservice setup manager 525-1 stores such information. Also, the contenttransmitter 525-2 receives data for a push service, that is, content ordata, from the CP/SP system 11 through the open interface processingunit 100 and the business logic processing unit 200, and manages thereceived data for the push service.

At a transmission time requested from the CP/SP system 11, the contenttransmitter 525-2 transmits the stored content or data to the legacysystem 30 with reference to the push service setup manager 525-1 so asto allow a user's mobile communication terminal 14 to receive thecontent. The message transmission can be performed through a legacysystem performing a cell broadcasting service, the CBBC 35, a legacysystem performing a SMS service, or the SMSC 32.

An application program interface (API) supported by the open mobilebusiness system having the push interface 525 for performing the pushservice includes a push service connection and a user authenticationAPI, an SMS based message transmission API, and a CBS based messagetransmission API.

The push service connection and user authentication API are provided bya function invoke_API that requests a push agent service device toperform the connection and user authentication process throughparameters. If this API is requested, a connection process and a userauthentication process are performed to use the push service of theCP/SP system 21 and the results thereof can be obtained.

The parameters of the push service connection and user authenticationAPI includes a template ID for push service connection and userauthentication, an authentication key assigned from the CP/SP system 21requesting the push service connection and user authentication, inputparameters used for push service connection and user authentication, andoutput parameters for transmitting the processing result.

The input parameter of the push service connection and userauthentication API includes information denoting a request service type,and the output parameter is formed of result codes and result messagesof the connection and user authentication.

As described above, when the CP/SP system 1 calls the push serviceconnection and user authentication API, the open interface processingunit of the open mobile business supporting system receives the requestand transfers the request to the business logic processing unit 200. Thebusiness logic processing unit 200 performs a biz template embodyinglogic for processing the push service connection and userauthentication. At first, the authentication for CP/SP and the userauthentication for a receiver of push information are performed. If theauthentication is successful, the input parameter with the serviceconnection and user authentication request is transmitted to the legacycooperation processing unit 500. It is transferred to the push servicesetup manager 525-1 of the push interface 525 through the MQ manager 511of the push agent service device, thereby registering it to the pushservice setup manager 525-1. The registration result is transferred tothe corresponding CP/SP system 11 through the business logic processingunit 200 and the open interface processing unit 100.

The SMS based message transmission API is provided by a functioninvoke_API that requests an SMSC performing an SMS to transmit pushinformation. If the API is requested, a process of transmitting a pushmessage using SMS is performed. Then, the result of message transmissionand message keys used to inquire transmitted message states are returnedto the CP/SP system 11.

In more detail, the parameters of the SMS based message transmission APIincludes a template ID embodied for transmitting message through the SMAbased pushing method, an authentication key assigned by the CP/SP system11 requesting the message transmission using the SMS based push method,an input parameter including a request service type, application programinformation applying to the push message, push message receiverinformation, a message priory, push message content, and a transmissionrequesting time, a result code that is a returned value, a resultmessage, and an output parameter formed of unique message keys generatedin the push agent service device for a push message transmissionrequest.

Hereinafter, the message transmission service using an SMS push methodwill be described in more detail. The CP/SP system 11 transmits an ID ofa template that requests message transmission using the SMS push method,an authentication key, and an input parameter by calling the SMS basedmessage transmission API. Then, the open interface processing unit 100of the open mobile business supporting system receives the API call, andtransfers the request of performing a template for transmitting amessage using an SMS push method to the business logic processing unit200. Then, the business logic processing unit 200 requests the SMS basedpush type message transmission to the push agent service deviceaccording to an embodiment of the present invention by transmitting thereceived input parameter to the push agent service device through theopen interface-processing unit 100. Herein, the message-transferringunit 800 is used to transmit the request.

The push interface 525 receives the message push service request throughthe MQ managing unit 511, stores the received request at the contenttransmitter 525-2, and transmits the message and the receiverinformation to the SMSC through the legacy interface 525-3 at atransmission time requested by the CP/SP system 11, thereby requestingthe message transmission. Then, the push interface 525 receives theresponse of the message transmission request from the SMSC, and composesa result message formed of a result code that denotes the success of theSMS based push service request, a result message transferred from theSMSC 32, and message keys generated in the push interface 505 foridentification based on the response. The push interface 525 transmitsthe composed result message to the business logic-processing unit 200through the message-transferring unit 800. Then, the business logicprocessing unit 200 returns the result thereof to the CP/SP system 11through the open interface-processing unit 22. Therefore, the CP/SPsystem 11 can receive the result message that reports whether therequest of SMS based push type message transmission successes or not andthe result thereof from the open mobile business supporting system.Furthermore, the business logic processing unit 200 receives messagekeys to identify the requests, thereby managing the states thereofaccording to the SMS based push type message transmission requests.

The CBS based push type message service is an API for performing a pushservice that transmits push information through a cell broadcastingservice (CBS) from a CP/SP system 11 to an assigned area. The CBS basedpush type message service is provided by a function invoke_API thatrequests the CMS based push type message service through parameters.

The parameter of the CBS based push type message transmission APIincludes an ID of a template that processes the CBS based push typemessage transmission, an authentication key of a CP/SP system 11 to usethe interface, a requested service type such as a popup serviceproviding information through a popup window or a ticker serviceproviding information through additional window disposed on the bottomsection of a displaying area, input parameter formed of applicationinformation of a mobile communication terminal to transmit acorresponding message, CBS channel information to transmit a message,information about a location where a message is transmitted to, amessage priority, message content to push, and transmission requesttimes, and an output parameter having a result code denoting whethermessage transmission successes or not as information for expressing theresult of requesting the CBS push service, a result message, and amessage key assigned according to the push service request.

When the CBS based push type message transmission API is called, theinput parameter formed of necessary information for the CBS push servicewith the CBS based push type message transmission request aretransferred to the legacy cooperation processing unit 500 through theopen interface processing unit 100 and the business logic processingunit 200. The content transmitter 525-2 creates an unique message keyfor the request, stores a push message to transmit among the inputparameter, transmits a message transmission command to the CBSC 35 totransmit a message at a message transmission request time included inthe input parameter, and receives the result thereof. The generatedmessage key, result code, and result message are returned to thebusiness logic processing unit 200. Then, the business logic processingunit 200 returns the received message key, result code and resultmessage to the CP/SP system 11 through the open interface processingunit 100.

Hereinafter, a download service of an open mobile business supportingsystem according to an embodiment of the present invention will bedescribed.

Since the download service is a frequently used service, it is may bedesirable to define one business logic by grouping an authenticationprocess, a content transform and transfer process, a URL transferprocess, and a billing process as one business logic, which areperforming in a mobile communication system, and to embody a biztemplate for the defined businesses logic. In the download service, adownload service providing procedure and infra resources of a mobilecommunication service can change according to whether a download servicerequester is matched with a download service subject, and whether awireless communication system of the download service subject isidentical to the wireless communication service of the downloadrequester. Therefore, it may be desirable to embody a biz templateaccording to a download service. For example, the download serviceaccording to the download service requester and the download servicesubject includes a service of “download to my phone” which downloadsselected content to a user's mobile communication terminal that requeststhe download service, and a service of “present it to other” whichdownload selected content to other user rather than a user requestingthe download service. The service of “present it to other” can bedivided into a service of “present content to the same mobilecommunication service provider” and a service of “present content to theother mobile communication service provider” according to whether thesubject who receiving the download service and the download servicerequester use the same mobile communication service provider or not.

Since the download subject is different according to the downloadservice type, a business logic totally differs for performingcorresponding services because billing conditions, a time of performinga billing process, and a download scheme.

FIG. 46 is a block diagram illustrating a structure for providing adownload service in an open mobile business supporting system accordingto an embodiment of the present invention.

In order to provide a download service, a download platform 37 ofperforming a download service of a wireless communication system, anauthentication system 36 for performing a user authentication process,and an MASS 31 for performing an SMS service. The legacy cooperationprocessing unit 500 includes an SMS interface 521 and an authenticationinterface 524, and a download interface 526 for cooperating with otherlegacy systems.

In FIG. 46, a gateway connects the wireless communication terminal 14,the CP/SP system 11, and the legacy system 30.

In the open mobile business supporting system, the OI processing unit100 provides an API call specification defined according to the downloadservice type to the CP/SP system 11. When the download service iscalled, the OI processing unit 100 defines a unique session key. Thedefined session key is used as an identification to provide consistencyto operations of the asynchronous business logic processing unit 200 andthe legacy cooperation processing unit 500. The OI processing unit 100provides a call message for a biz template corresponding to the calleddownload service to the business logic processing unit 200, receives theresult thereof from the business logic processing unit 200, and providesthe received result to the CP/SP system 11 through a standard API.

When the business logic processing unit 200 receives the call message ofa biz template for download service from the OI processing unit 100, thebusiness logic processing unit 200 performs the biz template. Whileperforming the biz template, the business logic processing unit 200requests the legacy cooperation processing unit 500 to perform apredetermined service if the predetermined resource of a legacy system30, such as the operations of a download platform, an authenticationsystem, and an MASS, are required, and receives the result thereof.Then, the business logic processing unit 200 collects the result ofperforming the biz template and the result transferred from the legacycooperation processing unit 500, and returns the final result of the biztemplate for download service to the OI processing unit 100.

That is, if a download function is required, the download interface 526of the legacy cooperation processing unit 50 is driven and requests thedownload of corresponding content while uploading related content to thedownload platform 37 of the legacy system 30. If the download interface526 requests the download of corresponding content, the authenticationinterface 524 of the legacy cooperation processing unit 500 requests theauthentication system 36 of the legacy system 30 to authenticate adownload requester or a download subject. In case of requiring messagetransmission for download call-back address, the SMS interface 521 ofthe legacy cooperation processing unit 500 requests the MASS 31 totransmit a text message having a call-back address.

A download service flow of the open mobile business supporting systemaccording to an embodiment of the present invention will be describedwith reference to FIG. 47 to FIG. 49.

A case of downloading predetermined content to a download requester'smobile communication terminal will be described with reference to FIG.47. When a predetermined mobile communication service user selects aservice of downloading predetermined content from services provided formthe CP/SP system 11, a download request message is transmitted to theCP/SP system 11 through a browser of a corresponding mobilecommunication terminal 14 in step S4101. Then, the CP/SP system IIanalyzes the download request message, calls an API related to a serviceof “download to my phone” because the download requester wants todownload predetermined content to own mobile communication terminal, andtransmits the selected content to the OI processing unit 100 in stepS4102.

The OI processing unit 100 analyzes the received message, and calls abiz template related to the service of “download to my phone” in stepS4103. The business logic processing unit 200 requests theauthentication system 36 to authenticate a user through theauthentication interface 524 and receives the authentication resultaccording to the flow of the biz template S4105. Then, the businesslogic processing unit 200 requests the download platform 37 to transmitthe predetermined content through the download interface 526, and thedownload platform 37 transforms the format of content and transmits aURL value of the transformed content in step S4106.

The business logic processing unit 200 returns the received URL value tothe CP/SP system 11 through the OI processing unit 100 in steps S4107and S4108. Herein, the returned URL includes a session key (Sesskey) toidentify a corresponding API call.

The CP/SP system 11 transfers the URL having the session key to thebrowser of the download requester's mobile communication terminal 14 instep S4109.

As described above, the download requestor confirms the download pageURL through the browser of the own mobile communication terminal 14 andselects a request to transmit the download page. Then, the request istransferred to the download platform 37 of the mobile communicationsystem by the displayed URL. The download platform 37 transmits thecorresponding content to the mobile communication terminal 14 at S4110.

The download completion of the download platform 37 is reported to thebusiness logic processing unit 200 through the download interface 526 instep S4111. Then, the business logic processing unit 200 transfers thebilling information for a corresponding download service to the billingprocessing unit 400 when the download completion is reported, in stepS4112.

In the steps of S4110 and S4111, a download service and a billingsubject are identified by the session key included in the URL.

Referring to FIG. 48, in case of transferring a request message of aservice of “present content to the other mobile terminal belonging tothe same mobile communication system” from the mobile communicationterminal 14 a to the CP/SP system 11 in step S4201, the CP/SP system 11calls an API related to the service of “present content to the othermobile terminal belonging to the same mobile communication system”thereby transmitting the selected content in step S4202. Then, the OIprocessing unit 100 analyzes the API call, and calls a biz template (BT)related to the service of “present content to the other mobile terminalbelonging to the same mobile communication system” from the businesslogic processing unit 200 in step S4203.

According to the called biz template related to the service of “presentcontent to the other mobile terminal belonging to the same mobilecommunication system” the business logic processing unit 200 requeststhe authentication system 36 through the authentication interface 524 toauthenticate a download requestor and a download subject, and receivesthe result thereof in step S4204. Then, the business logic processingunit 200 performs format transformation and URL creation by uploadingthe selected content to the download platform 37 through the downloadinterface 526, and receives the URL as the response message in stepS4205. Then, a message notifying that content are arrived from adownload requester as a present and a call back URL are transmitted tothe mobile communication terminal 14 of the download subject through theSMS interface 521 in steps S4206 and S4209.

Then, the completion of the service of “present content to the othermobile terminal belonging to the same mobile communication system” isnotified to the CP/SP system 11 through the OI processing unit 100.

Furthermore, the business logic processing unit 200 confirms the reportmessage from the SMS interface 521, and transfers the call back URLmessage from the MASS 31 to the mobile communication terminal 14. If theSMS receipt completion report is transferred in step S4210, itdetermines that the billing condition is satisfied, thereby transmittingthe related billing data to the billing processing unit 400 in stepS4211.

Referring to FIG. 49, in case of transferring a request message of aservice of “present content to the other mobile terminal belonging tothe other mobile communication system” from the mobile communicationterminal 14 to the CP/SP system 11 in step S4301, the CP/SP system 11calls an API related to the service of “present content to the othermobile terminal belonging to the other mobile communication system” fromthe OI processing unit 100, and transmits the selected content in stepS4302. The OI processing unit 100 analyzes the API call, and calls a biztemplate relate to the service of “present content to the other mobileterminal belonging to the other mobile communication system” to thebusiness logic processing unit 200 in step S4303.

According to the called biz template, the business logic processing unit200 requests the authentication system 36 through the authenticationinterface 524 to authenticate a download requestor, and receives theresult thereof in step S4304, and uploads the selected content to thedownload platform 37 through the download interface 526, therebyrequesting the service of “present content to the other mobile terminalbelonging to the other mobile communication system” in step S4305.

Then, the download platform 37 transmits the uploaded content to theother mobile communication system through the cooperation gateway of theother mobile communication system without transforming a format,transfers the download request message, and receives the responsethereof from the other company's wireless communication system in stepS4306.

After receiving the response from the other company's wirelesscommunication system, the download interface 526 transmits atransmission completion report to the business logic processing unit 200in step S4307. The business logic processing unit 200 returns a resultmessage of transmission completion to the CP/SP system 11 through the OIprocessing unit 100 in steps S4308 and S4309.

After determining that the service of “present content to the othermobile terminal belonging to the other mobile communication system” iscompleted, billing data of corresponding download requestor istransmitted to the billing processing unit 400 in step S4310.

As described above, the open mobile business supporting system accordingto an embodiment of the present invention supports the download serviceof the CP/SP system.

FIG. 50 is a block diagram illustrating an operating and managementsystem (OMS) 700 in an open mobile business supporting system accordingto an embodiment of the present invention.

Referring to FIG. 50, the OMS 700 includes a database 710 for storingtraffic related data collected by the open mobile business supportingsystem, and statistical data generated based on the collected trafficrelated data, a DB manager 720 for managing the database 710 by creatingstatistical data and service call tracking data based on the storedtraffic related data stored in the database 710, storing the createddata in the database 710 or deleting the data from the database 710, anda presentation unit 730 for providing an operator interface, receivingrequests such as a request of monitoring performance from an operatorthrough the operator interface; reading data corresponding to thereceived request from the database 710, and providing the read data tothe operator.

In more detail, the database 710 is a device to store information aboutthe performance and the states of low-level systems in the open mobilebusiness supporting system. The database 710 manages various tablesincluding a biz template state information table for recording stateinformation of biz templates, an API parameter information table forrecording information about parameters of API defined according to eachtemplate in an open interface provided to a CP or an SP, a first sessionstate information table for managing state information per each sessionperformed in an infra channel providing unit, a second session stateinformation table for managing state information per each session of thelegacy cooperation processing unit and the billing processing unit, athreshold setup table for recording thresholds for determiningperformance or malfunction of each low-level system in the open mobilebusiness supporting system, a first response time threshold setup tablefor setting up response time thresholds per each biz template performedin the open mobile business supporting system, a second response timethreshold setup table for setting up response time thresholds per eachbiz template performed in the open mobile business supporting system, adata collecting time threshold setup table for setting up a thresholdfor a time for collecting traffic related data per each low-levelsystem, a last data transmission time table for recording the last timeof transmitting traffic related data to the OMS of each low-levelsystem, a used amount statistical table for recording used amount pereach low-level system.

The DB manager 720 includes a log processing module 721 for transformingcall tracking data to a predetermined file format, storing thetransformed data in the database 710, and deleting the system log, a DBmanaging module 721 for deleting a transaction log for managing thedatabase 710, a deletion managing module 723 for deleting data with avalid data expired, for example, three months, among statistic datastored in the database 710, a combine managing module 724 for creatingstatistic data with reference to traffic related data recorded in thedatabase 710 at a predetermined cycle, for example, a day, and a dataaccess module 725 for performing an access function of the database 710for the modules 721 to 724.

The presentation unit 730 includes a management site providing unit 731for providing a web service based managing graphic user interface to amanager to monitor the open mobile business supporting system andmalfunctioning details thereof, to setup thresholds, to track a call anda traffic, and to calculate statistics of used amount, and to managelogs, and a monitoring logic processing unit 732 for reading datacorresponding to selected items from a manager through the managementsite providing unit 731 and proving the read data to the management siteproviding unit 731.

The monitoring logic processing unit 732 includes a statistic inquirymodule 733 for extracting used amount statistic data based on entirestructure of the open mobile business supporting system, a monitoringstructure managing module 734 for setting a threshold for monitoring, acall tracking managing module 735 for providing a call tracking functionfor a predetermined service call requested through the management siteproviding unit 731, a group success managing module 736 for providingsuccession times-traffic graph from the current time to a predeterminedpast time for example, three hours, six hours, twelve hours, and twentyfour hours, a fine monitoring managing module 737 for showingmalfunctioning details of each low-level system in the open mobilebusiness supporting system, a monitoring managing module 738 for showingthe number of tries, the number of success, a succession rate, and anaverage response time per each low-level system of the open mobilebusiness supporting system and showing states of each system withreference a predetermined threshold, and a data access module 739 forallowing the modules to fetch necessary data from the database 710 byproviding an access function.

In the OMS 700 according to an embodiment of the present invention, theOI processing unit 100, the billing processing unit 400, and the legacycooperation processing unit 500 are cooperated using FTP, and thebusiness logic processing unit 200 and the infra channel providing unit300 are cooperated and commonly use data through the ODBC open databaseconnectivity.

Each of low-level systems in the open mobile business supporting system,such as the OI processing unit 100, the business logic processing unit200, the infra channel providing unit 300, the legacy cooperationprocessing unit 500, and the web service providing unit 600, transmitsthe generated system logs to the OMS 700 through the above describedcooperation structure.

In order to monitor performance malfunctioning, the OMS 700 reads thesession information of the OI processing unit 100 and the business logicprocessing unit 200, the session information of the billing processingunit 400, and the session information of the legacy cooperationprocessing unit 500 from the MMDB 900 at a predetermined period, forexample, every five minutes, and stores the read session informationinto the database 710.

The OMS 700 regularly receives the state information of biz template andbiz object from the OI processing unit 100 and the business logicprocessing unit 200, and stores the received state information into thedatabase 710.

The OMS 700 regularly receives the session state information from theinfra channel providing unit 300, the state information of bizobject/template, and parameter information, and stores the receivedsession state information, state information and the parameterinformation into the database 710.

The OMS according to an embodiment of the present invention stores onlytraffic related data in the database 710, and reads basic informationrelated to configuration, performance, and malfunctioning of the openmobile business supporting system from the database of the open mobilebusiness supporting system, the registry DB 1000 in FIG. 15.

The system log generated from the low-level device in the open mobilebusiness supporting system is transmitted to a predetermined area of thedatabase 710 through FTP at a predetermined period, thereby allowing thesystem log to be inquired by sits provided from the presentation unit730 according to need.

The OMS 700 provides a monitoring function for a service call process.That is, the OMS 700 compares performance and malfunctioning data, whichis monitoring data collected according to the hardware configuration ofthe open mobile business supporting system and stored in the database710, with a threshold value for detecting load increment or operationmalfunctioning. When the OMS 700 successfully access the database 710 byan authenticated manager, the OMS 700 inquires the configurationinformation of the open mobile business supporting system. Then, the OMS700 inquires monitoring data corresponding to a setup period forexample, five minutes. After inquiry, the OMS 700 compares the thresholdvalue with the inquired monitoring data, and displays the comparisonresults through a predetermined display unit.

The OMS 700 provides a function of inquiring a malfunction state of theopen mobile business supporting system. The malfunction state inquiringfunction provides malfunctioning details of the low-level systems of theopen mobile business supporting system to a manager. When a managerselects the malfunction state inquiring function, the OMS 700 determineswhether the manager has a right of using the function or not. If themanager has the right, the OMS 700 loads data that composes amalfunction detail inquiring page by accessing a DB that stores web siteinformation, accesses the database 710 through the data access module739, reads the configuration information of the open mobile businesssupporting system and recent monitoring data, for example, monitoringdata collected within five minutes, composes a related web page bycombining the read data with the malfunction detail inquiring page, andoutputs the composed web page through a predetermined display unit.

The OMS 700 provides a function of managing thresholds. That is, the OMS700 provides a threshold managing menu through the managing siteproviding unit 731. When a manager selects the provided menu, the OMS700 determines whether the manager has a right to use the provided menuor not. If the manager has the right, the OMS 700 access the database710 through the data access module 739, reads the threshold values suchas threshold values of biz objects, and threshold values of biztemplates, and displays the read threshold values through apredetermined display unit. The manager is allowed to change thethreshold values outputted through the display. The change thresholdvalues are transferred to the monitoring configuration managing module734 through the managing sit providing unit 731. The monitoringconfiguration managing module 734 transfers the changed threshold valueto the database 710, and the database 710 stores the changed thresholdvalue.

The OMS 700 provides a function of tracking a predetermined servicecall. The OMS 700 provides the service call tracking function throughthe managing site providing unit 731. If the menu of the service calltracking function is selected by a manager, the OMS 700 authenticatesthe manager whether the manager has the right of using the selectedfunction or not. If the manager has the right, the OMS 700 connected tothe database 710 through the data access module 739 and provides a calltracking search graphic user interface to the manager through a site.When the manger selects a search condition, the OMS 700 read calltracking data from the database 710 according to the search conditionand displays the read call tracking data through a predetermined displayunit.

The OMS 700 provides a function of providing a traffic graph. When amanager selects a traffic inquiring menu among performance andmalfunction managing menus, the OMS 700 authenticates the manager tohave the right of using. If the manager has the right, the OMS 700access the database 710 through the data access module 739, readstraffic data satisfying the conditions set by the manager, modifies theread traffic data as a graph, and outputs the graph through apredetermine display unit.

The OMS 700 provides a function of inquiring used amount statistic data.When a manager inquires the used amount through the managing sideproviding unit 731, the OMS 700 authenticates the manager to have theright of using. If the manager has the right, the OMS 700 access thedatabase 710 through the data access module 739, reads statistic datasatisfying search conditions set by the manager, and displays the readstatistic data.

The OMS 700 performs a call tracking function through the log processingmodule 721. The log processing module 721 regularly connects to thedatabase 710 through data access module 725 at a predetermined period,for example, one day. The log processing module 721 read the system logof each service call stored for a predetermined period, for example, forone day, creates a call tracking data file, and stores the created calltracking data file. The created system log is deleted.

As described above, the OMS 700 of the open mobile business supportingsystem according to an embodiment of the present invention stablymanages traffic related data fir the open mobile business supportingsystem including the OI processing unit 100, the business logicprocessing unit 200, the infra channel providing unit 300, and thelegacy cooperation processing unit 500, processes the traffic relateddata, and effectively displays the information about the performance andthe malfunction state of the open mobile business supporting systembased on the processed traffic related data, thereby improvingefficiency of supporting open mobile business.

FIG. 51 is a block diagram illustrating a web service providing unit inan open mobile business supporting system according to an embodiment ofthe present invention.

Referring to FIG. 51, in the open mobile business supporting systemaccording to an embodiment of the present invention, the web serviceproviding unit 600 includes a web service unit 610 for providing a webbased user interface to a user of the open mobile business supportingsystem, a logic processing unit 620 for performing a registrationoperation and an inquiry operation according to the user's requestthrough the web service unit 610, and a DB access processing unit 630for accessing a repository DB 1000, reading or writing data from/to therepository DB 1000 by the request of the logic processing unit 620.

The web service unit 610 includes a first web site 611 for providing aweb based user interface to a CP or a SP using a biz template in theopen mobile business supporting system, a second web site 612 forproviding a web based user interface for developing and managing theopen mobile business supporting system, and first and second web formevent processing modules 613 and 614 for processing and respondingevents generated from pages of the first and second web sides 611 and612, checking validity of user inputs, and processing events when a pageis loaded.

The first and second web sits 611 and 612 share the logic processingunit 620 and the DB access processing unit 630.

The repository DB 1000 functions as a common storage space for sharingdata commonly managed in the open mobile business supporting system. Therepository DB 1000 stores a user right table, a real time cooperationresult table of a content aggregation & syndication system (CASS) 38, abiz template information table, a new biz template analysis/designresult table, an announcement table, a resource table, a service examinerequest/examine/request state/information table, a user authenticationtable, a biz object information table, a biz object change informationtable, a biz object using list table, a biz template and biz objectrelation table, a distribution information of a biz template table, auser information table, a service information table, a biz templatemodification/request/approval change information table, a biz templateuse IP information table, a CP information table, an error code table, aservice information/IP address/authentication key table, a serverinformation table of open mobile business supporting system, a webserver information table, an access managing history information tableof a CP and/or an SP, and common information for supporting developmentand use of the open mobile business supporting system.

The web service providing unit 600 cooperates and commonly uses datawith the CASS 38 managing content in a mobile communication systemthrough the repository DB 1000, and supports reliable data cooperationwith internal devices of the open mobile business supporting system.

Furthermore, the repository DB 1000 stores data managed by the webservice providing unit 600, and synchronizes information of a CP, aservice, a web server, and a user through cooperating with the CASS 38.

The web service providing unit 600 cooperates with the open interfaceprocessing unit 100, the business logic processing unit 200, the infrachannel providing unit 300, the billing processing unit 400 and the OMS700 in the open mobile business supporting system for providing afunction of setting environmental setups and a function of monitoringstatistic data or malfunction states. The web server providing unit 600cooperates with the business logic processing unit 400 through the MQserver for distributing the biz template and/or the biz object. The webserver providing unit 600 cooperates with the CASS 38 that managescommon information about a CP, a service, and a user through HTTP inreal time. The web server providing unit 600 cooperates with the OIprocessing unit 100 and the OMS 700 through communication in order toallow a manager to inquire content of environmental setup per a server.Furthermore, the web server providing unit 600 communicated with theinfra channel providing unit 300 through TCP.

Moreover, the web service providing unit 600 separates a user view, alogic process, and a data access process in order to effectively expand,maintain, and repair according to need.

The web service providing unit 600 manages the repository DB 1000storing the common data of each low-level apparatus of the open mobilebusiness supporting system. The repository DB 1000 commonly uses commondata through the CASS 38 of the wireless communication system, andshares the data. The CP/SP information, service information and userinformation, which are managed through the CASS 38, are commonly usedfor inquiring purpose. Such an information is not additionally managedin the web service providing unit 600.

The first web site 611 is provided to a CP or an SP that accesses thefirst web site 611 to use the open mobile business supporting system.The first web site 611 supports the use of the open mobile businesssupporting system. Therefore, the first we site 611 provides a functionfor providing log-in to confirm a registered user, a function forinquiring a standard API information for a biz template provided fromthe open mobile business supporting system, a function for managingrequests of using a biz template that allows a CP/SP or a user torequest a biz template or to cancel/modify the previous requests, afunction for providing technical materials and managing inquires andresponses, a function for providing announcement or inquires andresponse for a user, a function for inquiring a service result list, afunction for requesting an authentication key, and a function forinquiring the current condition of using API by receiving theauthentication key.

The second web site 612 is provided for managing and developing the openmobile business supporting system. The second web site 612 includes afunction for processing log-in for allowing a registered manage toaccess, a function for inquiring the details of requests to use a biztemplate, a function for registering a service checking result forapproval/cancel/deletion, a function for processing a service checkrequest for issuing an authentication key to use a biz template orchange authentication information state, a function for inquiringannouncement, a function for designing a new biz template, registering aanalysis result of the new biz template, and inquiring, a function formanaging a standard API for a CP and/or an SP and managing generaldocuments, a function for managing bulletin board/announcement of thefirst web site 611, a function for inquiring a repository DB andcooperation detail, a function for managing server information of theopen mobile business supporting system, a function for managing biztemplate information, a function for managing biz object information, afunction for managing common code and error codes, a function formanaging an operator/manager right/access, a function for approving theuse of a biz template, a function for issuing an authentication key, afunction for inquiring information of a service using a biz template,and a function for inquiring and managing information of a system usingan API of the infra channel providing unit 300 and managing a currentcondition thereof.

The logic processing unit 620 performs an inquiry operation and aregistration process for major data provided through the first andsecond web sites 611 and 612.

FIG. 52 is a block diagram illustrating a logic processing unit 620according to an embodiment of the present invention. Referring to FIG.52, the logic processing unit 620 according to an embodiment of thepresent invention includes a service development support managing module621, an event support managing module 622, a technical support managingmodule 623, a malfunction monitoring module 624, a statistic inquirymodule 625, and an operating and managing module 626. The servicedevelopment support managing module 621 provides a function for managingresources for the open mobile service supporting system, a function formanaging data of a biz template and biz object, and a function forrequesting and approving a predetermined process related thereto. Theevent support managing module 622 provides a function for requesting andapproving events, and a function for registering, modifying, andinquiring information. The technical support managing module 623provides a guide for developing the open mobile business supportingsystem and a function for registering, modifying, deleting, andinquiring technical materials and bulletin board. The malfunctionmonitoring module 624 performs a function for monitoring the open mobilebusiness supporting system in real time, a function for managingthresholds for monitoring, a function for inquiring traffic, a functionfor monitoring session information in real time, a function for trackinga call through a phone number, and a function for inquiring malfunctioninformation. The statistic inquiry module 625 performs a function forinquiring billing statistic according to an event, a CP, a service, abiz template, an error, and a term, and a function for used amountstatistic according to an event, a CP, a service, a biz template, a bizobject, an infra, and a term. The operating and managing module 626manages an integrated supporting apparatus. The operating managingmodule 626 registers, modifies, deletes, and inquires the announcementin a bulletin board, manages the right of a site user, managesregistration per a server of the open mobile business supporting system,inquires environmental setup, manages common codes and error codes,inquires a result of cooperating with a legacy system managing contentand cooperation information thereof, and managing access of a siteoperator.

In more detail, the service development support managing module 621includes: a biz object manager for registering, modifying, and inquiringa biz object; a biz template manager for registering, modifying, andinquiring a biz template; a biz object information manager for creatinginformation about a biz object, and distributing the biz objectinformation; a biz template information manager for creating informationabout a biz template, and distributing the biz template information; aBT manager for requesting service check, requesting an API, inquiring arequest list, a manager, and a user, and issuing an authentication key;a BT information manager for inquiring information and current conditionfor authentication key through the BT manager; and a manager forinquiring, registering, deleting, and modifying the API of the infrachannel providing unit 300. The event support managing module 622includes an even list manager for managing a function of inquiring eventcurrent condition. The operation managing module 626 includes: a codeinformation manager for registering, deleting, and inquiring commoncodes; a community manager for managing registration, modification,deletion, and inquiry of bulletin board, announcement, and FAQ; an errorcode manager for managing registration, modification, deletion, andinquiry of error code; and a file information manager for managing afunction of inquiring a file related to a biz object and a biz template,and a download function.

The logic processing unit 620 includes a log-in manager for processinglog-in to the first and second web sites 611 and 612, and an access IPmanager for registering, editing, deleting, and inquiring an IP of thesecond web site 612.

In FIG. 51, the DB access processing unit 630 manages the access of therepository DB 1000, and defines a common data access class that definesa method for inserting, deleting and updating data.

The web service providing unit 600 provides a real time interface and anon-real time interface. The web service providing unit 600 cooperatesand shares data with the repository DB 1000, the CASS 38, the openinterface processing unit 100, and the business logic processing unit200 through HTTP in real time. If data is modified in the CASS 38, theCASS 38 transmits the modified data to the repository DB 1000 usingHTTP. Herein, the sharing data is CP information, service basicinformation, service IP information, and web server information.

For example, if a CP or an SP is authenticated and the information of abiz template is modified through a second web site 612 provided from theweb service providing unit 600, the related information and the modifieddata are transferred to the open interface processing unit 100 using afunction Selvlet through an HTTP web service, and the open interfaceprocessing unit 100 provides the results to other devices through theweb service providing unit 600.

The repository DB 1000 shares data with a cooperating system requiring aone-off data using an FTP scheme or a database view scheme in non-realtime. The sharing data includes billing information or web serverinformation. If the data is provided to the cooperating system throughthe database view scheme, following advantages are provided. That is,additional cooperation modules are not required. Security and stabilityare guaranteed because the data are selected and provided throughcontrolling security information and fields by a manager. It is possibleto provide related information by properly processing complicatedrelated tables or the formats thereof. Furthermore, it is possible toupdate new table through simple modification of a view.

FIG. 53 is a flowchart illustrating a method for processing a mobileoriented (MO) message using an open mobile business supporting systemaccording to an embodiment of the present invention.

A short message service (SMS) or a multimedia message service (MMS)between a CP/SP system 11 and a mobile communication terminal 14includes a mobile oriented (MO) message service and a mobile terminated(MT) message service.

The MO message service is a service to transfer a message to acorresponding CP/SP system 11 when a short message or a multimediamessage is transmitted to a predetermined assigned number, for example,##6650, from a user's mobile communication terminal 14 after a terminalnumber of a receiving side CP/SP system 11 is assigned to thepredetermined number, for example, ##6650.

Referring to FIG. 53, the user MO message service is performed by the OIprocessing unit 100, the business logic processing unit 200, and thelegacy cooperation processing unit 500 in the open mobile businesssupporting system according to an embodiment of the present invention.In order to provide the user MO message service, the OI processing unit100 includes an infra channel interface 100 a and an open outputinterface 100 b. Also, the legacy cooperation processing unit 500includes a MO cooperating unit 527.

The infra channel interface 100 a is disposed in the OI processing unit100, and receives an MO SMS message or MO MMS message from the userterminal 14 through an MP/MMSC 39. The MP denotes an SMS dispatchingSystem, and the MMSC denotes a device transmitting an MMS message. Theinfra channel interface 100 a receives the MO message from the userterminal 14, and calls a business logic related to the MO message formthe business logic processing unit 200.

The business logic processing unit 200 performs a biz template assignedfor the MO message through cooperating with the MO cooperating unit 527of the legacy cooperation processing unit 500. As described above, thebiz template is formed of properties of biz objects, an order ofperforming the biz objects, the expression of a conditional branch,input parameter information for performing the biz objects, a method ofprocessing data, information about output parameters exposed afterperforming a biz template, and time-output setup information. FIG. 54and FIG. 55 show examples of a business template previously set forprocessing an MO message. Referring to FIG. 54 and FIG. 55, a biztemplate for processing an MO message can group unit functions amongservice logics of the CP/SP system II for processing the user MOmessage. Such a biz template embodied to perform a biz logic that is alow-level function performed by a wireless communication system. The biztemplate includes at least one or a plurality of biz objects. FIG. 54shows a biz template processed in the business logic processing unit 200for processing an MO SMS message, and FIG. 55 shows a biz templateprocessed in the business logic processing unit 200 for processing an MOMMS message. The biz template can be formed in various types and formsaccording to a service type provided from the CP/SP system 11.

The business logic processing unit 100 performs a biz template that ispreviously defined according to an MO message as shown in FIG. 54 andFIG. 55, and provides the result of performing the biz template to theCP/SP system 11 that is the destination of a corresponding MO messagethrough the open output interface 100 b.

The MO cooperating unit 527 is disposed in the legacy cooperationprocessing unit 500. The MO cooperating unit 527 provides theinformation of a destination of the MO message and option information tothe business logic processing unit 200 in response to the business logicprocessing unit 200. Herein, the option information includes informationabout a billing type and a call type. Herein, the billing typeinformation is information about whether a user applies for a prepaymentplan or a post payment plan. The post payment plan can include varioustypes of post payment plans or pre/post integrated payment plansaccording to the policy of a mobile communication service provider. Thecall type information is information related to whether a messagetransmitted from the user terminal 14 is an MO message, or an MTmessage, or whether an MT message is processed continuously afterprocessing an MO message. The destination information includes an IPaddress and port information for the CP/SP system 11. Therefore, thebusiness logic processing unit 200 composes a business template invarious forms using the destination information and the optioninformation received from the MO cooperating unit 527.

The open output interface 100 b is disposed in the open interfaceprocessing unit 100. The open output interface 100 b receives the resultof performing business logic by the business logic processing unit 200,and transmits the received result to the CP/SP system 11. The openoutput interface 100 b uses an integrated specification for SMS and MMSwhen transmitting an MO message to the CP/SP system 11.

Referring to FIG. 53, a procedure of processing an MO message in theopen mobile business supporting system according to an embodiment of thepresent invention will be described.

In step S4701, a user transmits an SMS or MMS message using his ownterminal 14 to a pre-assigned terminal number of a receiving side CP/SPsystem 14, for example, #6650. The MP/MMSC 39 transfers the SMS or MMSmessage, which is transmitted to the pre-assigned terminal number, tothe infra channel interface 100 a in the OI processing unit 110 of theopen mobile business supporting system in step S4702.

Then, the infra channel interface 100 a calls a predetermined biz logiccorresponding to the SMS or MMS message to the business logic processingunit 200, and requests the business logic processing unit 200 to performthe biz template for the business logic in step S4703.

In order to perform the biz template, the business logic processing unit200 requests the destination information and the option information ofthe MO message from the MO cooperating unit 527. The MO cooperating unit527 provides the destination information and the option information forthe MO message to the business logic processing unit 200 in step S4704.Therefore, the business logic processing unit 200 can compose businesstemplates in various forms using the destination information and theoption information from the MO cooperating unit 527.

The business logic processing unit 200 performs a biz template definedfrom predetermined business logic for the MO SMS or MMS message, andtransmits the result of performing the biz template to the open outputinterface 100 b of the OI processing unit 100 in step S4705.

Then, the open output interface 100 b transfers the received result ofperforming the biz template from the business logic processing unit 200to the CP/SP system 11, thereby ending the procedure of processing theMO message using the open mobile business supporting system according toan embodiment of the present invention in step S4706.

FIG. 56 is a block diagram and a flowchart illustrating an MT messageprocessing apparatus using the open mobile business supporting systemaccording to an embodiment of the present invention.

The MT message service is a service to provide an SMS or MMS messagesuch as a text, a picture, and a multimedia file from a CP/SP system 11to a user's mobile communication terminal 14. In order to process the MTmessage, the legacy cooperation processing unit 500 further includes anMT cooperating unit 528.

Referring to FIG. 56, the OI processing unit 100 receives a user MTmessage provided from the CP/SP system 11, and calls a biz templaterelated to the MT message for the business logic processing unit 200.The OI processing unit 100 creates a unique session key according to arequest of performing each biz template constituting an MT messageservice provided from the CP/SP system 11 and manages the createdsession key. Therefore, the created session key can be used to identifybusiness logics processed in the open mobile business model supportingsystem. The OI processing unit 100 provides a web service based standardAPI type business logic call mechanism in order to allow access withoutbeing limited by a client type.

The business logic processing unit 200 performs a predetermined biztemplate for the MT message through cooperating with the MT cooperatingunit 528. As described above, the biz template is formed of theproperties of biz objects, an order of performing the biz objects, theexpression of a conditional branch, input parameter information forperforming the biz objects, a method of processing data, outputparameter information exposed after performing the biz template, andtime-out setup information. FIG. 57 and FIG. 58 show biz templatespreviously setup for processing an MT message. As shown in FIG. 57 andFIG. 58, in the open mobile business supporting system, the biz templateis embodied by grouping unit functions among service logics of the CP/SPsystem 11 for processing an MT message. That is, the biz template isembodies by grouping at least one or a plurality of biz objects forprocessing an MT message. FIG. 57 shows a biz template processed in thebusiness logic processing unit 200 for processing an MT SMS messageaccording to an embodiment of the present invention. FIG. 58 shows a biztemplate for processing an MT MMS message according to an embodiment ofthe present invention. Such a biz template for processing an MT messagecan vary in various forms according to a service type provided from theCP/SP system 11.

The business logic processing unit 200 performs a biz template definingpredetermined business logic for the MT message. In performing the biztemplate, the SMS MT message or the MMS MT message is transmitted to theuser terminal 14 through the MP/MMSC 39 in a legacy system throughcooperating with the MT cooperating unit 528 in the legacy cooperationprocession unit 500 in case of receiving an instruction for performingthe biz objects forming the biz template.

The MT cooperating unit 528 relays the cooperation between the businesslogic processing unit 200 and the mobile communication legacy system 30to transmit the MT message to the user terminal through the MP/MMSC 39so that the business logic processing unit 200 performs the biztemplate.

With reference to FIG. 56, a procedure of processing an MT message inthe open mobile business supporting system according to an embodiment ofthe present invention will be described.

The CP/SP system 11 transmits a predetermined SMS or MMS message to theOI processing unit 100 in step S5301.

Then, the OI processing unit 100 calls a biz template related to the MTSMS message for the business logic processing unit 200 in step S5302.

The business logic processing unit 200 performs a biz template shown inFIG. 57 and/or FIG. 58, which is defined based on a business logiccalled corresponding to the MT SMS or MMS message. As described above,while the business logic processing unit 200 performs a biz templaterelated to the MT message, the business logic processing unit 200requests the MT cooperating unit 528 in the legacy cooperationprocessing unit 500 to cooperate with the MP/MMSC 130 in a mobilecommunication legacy system in order to perform the biz template in stepS5303.

Then, the MT cooperating unit 528 requests the MI or MMSC 39 to transmitthe MT message in step S5304. The MP or MMSC 39 receives the MT messageand transfers the received MT message to the user terminal 14, therebyprocessing the MT message through the open mobile business systemaccording to an embodiment of the present invention.

FIG. 59 is a flowchart illustrating a procedure for processing an MT MSMmessage after processing an MO SMS message using an open mobile businesssupporting system according to an embodiment of the present invention.

Typically, a billing process for an MO message processing service and abilling process for an MT message processing service are independentlyperformed. If an error is generated in the MT message processingprocedure after transmitting a predetermined SMS message or MMS messageto a CP/SP system 11 using a user terminal 14 based on the typical MOmessage processing scheme, the SMS or MMS message can not reach areceiver. Although the user did not receive the SMS or MMS message dueto such an error, a service fee is charged to a user according to thetypical service scheme.

In the present embodiment, however, the sessions for MO message and forthe MT message are managed in single procedure using the open mobilebusiness supporting system. Therefore, a related service fee is chargedonly if the MO message and the MT message service are normally andcompletely finished without generating error.

Referring to FIG. 59, in an MO SMS delivering procedure, a usertransmits an SMS message to the MASS 32, an SMS dispatching system,using own user terminal 14 in step S5301. The SMS message is a phone toCP/SP message provided from the user terminal 14 to the CP/SP system 11.

Then, the MASS 32 transmits the SMS message to the infra channelinterface 100 a in step S5302, and receives the response in step S5303.

The infra channel interface 100 a requests the characteristicsinformation of the MO message such as the destination information andthe option information from the MO cooperating unit 527 through thebusiness logic processing unit 200 in steps S5304 and S5305. Theredestination information includes an IP address and port information ofthe CP/SP system 11, and the option information includes informationrelated to a billing type and a call type.

As a respond of the request, the MO cooperating unit 527 transfers thecharacteristics information of the MO message such as the destinationinformation and the option information to the infra channel interface100 a through the business logic processing unit 200 in steps S5306 andS5307.

The infra channel interface 100 a creates a session for transmitting theMO message using the destination information and the option informationof the received MO message, and inputs the information of the session tothe MMDB 900 in step S5308. When creating the session for transmittingthe MO message in the present embodiment, billing information inputs forlater billing process for the MO message transmission, and the billinginformation is managed through entire session for the MO message.

Then, the infra channel interface 100 a requests a correspondingbusiness logic from the business logic processing unit 200 using thecreated session for the MO message by calling a business logic for theMO SMS in step S5309.

Then, the business logic processing unit 200 performs a biz template forthe called business logic, and transfers the result thereof to the CP/SPthrough the open output interface 100 b in steps S5310 and S5311. Then,the business logic processing unit 200 receives the result of MO SMStransmission as a response in steps S5312 and S5313.

Then, the business logic processing unit 200 transmits the result ofperforming the biz template for the MO message to the infra channelinterface 100 a in step S5314.

The infra channel interface 100 a determines whether the transmitted MOmessage is normally transmitted to the CP/SP system 11 based on theresult of performing the biz template. If the MO message is successfullytransmitted to the CP/SP system 11, the infra channel interface 100 acontinuously sustains the session for the MO message for continuouslyprocessing the MO message. The infra channel interface 100 a, however,terminates the session in step S5315, if the MO message transmission isfailed.

In an MO SMS delivery report procedure, the CP/SP system 11 transmits areport message to the business logic processing unit 200 through theopen output interface 100 b in order to inform that the MO message issuccessfully transferred in steps S5316 and S5317. Since a step oftransmitting the MT message with the session sustained is performedafter processing the MO message in the present embodiment, the stepsS5316 and S5317 can be cancelled.

Then, a procedure of MT SMS deliver is performed. If the MO message issuccessfully transferred to the SP/SP system 11 in step S5315, the CP/SPsystem 11 requests the open web interface 100 c to transmit a CP/SP toPhone direct MT SMS message from the CP/SP system to the user terminal14 in step S5318.

Then, the open web interface 100 c creates a session for an MT messagebased on the received MT SMS message transmission request and stores theinformation of the created session to the MMDB 900 in step S5319. In thepresent embodiment, the session key for the MO message is required to besustained in case of continuously processing the MT message afterperforming an MO message. In the present embodiment, billing informationinputs for a billing process for the MT message transmission when thesession for the MT message is created, and the billing information ismanaged through the entire session for the MT message.

In the step S5319, if a session for the MT message is created, the openweb interface 100 c calls business logic for the MT SMS for the businesslogic processing unit 200 using the created session information, therebyrequesting a corresponding biz logic to be processed in step S5320.

Then, the business logic processing unit 200 performs a biz templatethat defines the previously defined business logic for the MT message.When the biz template is performed, if the business logic processingunit 200 requires cooperating with a legacy system, the business logicprocessing unit 200 requests the MT cooperating unit 528 to transmit theMT message through the MASS 32 in the legacy system in step S5321.

Then, the MT cooperating unit 528 transmits the MT SMS message to theuser terminal by cooperating with the MASS 32, and transmits the resultof transmitting to the business logic processing unit 200 in step 35322.

Afterward, the business logic processing unit 200 provides a result oftransmitting the MT SMS message to the user terminal by performing thebiz template for the MT message as described above to the open webinterface 100 c in step S5323. The open web interface 100 c provides theresult of transmitting the MT SMS message to the CP/SP system 11 in stepS5324.

In a procedure of MT SMS delivery report, the MT cooperating unit 528transmits an MT SMS deliver report message to the business logicprocessing unit 200 to inform that the MT SMS message is successfullytransmitted in step S5325.

Then, the business logic processing unit 200 confirms the MT SMS messageprocess successfully end by analyzing the received MT SMS deliveryreport message and terminates the session for the MT message in stepS5327.

Then, the business logic processing unit 200 transmits an MO SMS deliverreport message to the infra channel interface 100 a to inform that theMO SMS message is successfully transmitted in step S5327.

Then, the infra channel interface 100 a confirms that the MO message andthe MT message are successfully transmitted based on the received MO SMSdelivery report message, and terminates the sessions for the MO messageand the MT message in step S5328. Finally, the MO MT cooperation messageprocessing procedure according to an embodiment of the present inventionends.

As described above, if the MO message and the MT message aresuccessfully transmitted, billing operation for the MO and MT messagetransmission is processed as a batch job based on the billinginformation inputted in steps S5307 and S5319.

Therefore, various business logics including the MO-MT message processcan be developed and applied using the open mobile business supportingsystem according to an embodiment of the present invention. Although anerror is generated in processing an MT message after transmitting an SMSmessage to the CP/SP system 11 through the MO message processing scheme,a service fee for processing the MO message is not charged to a user ifthe SMS message is not successfully reached to a user. Therefore, aservice fee for transmitting an SMS or MMS message is reasonably chargedto a user according to an embodiment of the present invention.

FIG. 60 is a diagram illustrating a procedure of processing an MT MMSmessage after processing an MO MMS message using an open mobile businesssupporting system according to an embodiment of the present invention.

As shown in FIG. 60, after processing an MO MMS message using the openmobile business supporting system according to an embodiment of thepresent invention, MT MMS message processing steps S5401 to S5428 aresimilar to the MO-MT message processing steps S5301 to S5328. Therefore,overlapped descriptions thereof are omitted. The MO-MT MMS messageprocessing steps in FIG. 60 are identical to the MO-MT messageprocessing steps in FIG. 59 except following steps. The business logicprocessing unit 200 cooperates with the MMSC 33 of a legacy system totransmit the message so as to process an MMS message. A report messageis transmitted to a long message service center (LMSC, not shown) andreceives a response thereof in steps S5430 to S5436 in order to enablethe LMSC to independently perform a billing process, which is connectedto the MMSC 33 to confirm the transmission of the MMSC.

FIG. 61 is a diagram illustrating a procedure of processing an MO SMSmessage after processing an MT SMS message using an open mobile businesssupporting system according to an embodiment of the present invention,and FIG. 62 is a diagram illustrating a procedure of processing an MOMMS message after processing an MT MMS message.

A method of processing an MO message after processing an MT message inFIG. 61 and FIG. 62 is different from that of processing an MT messageafter transmitting an MO message shown in FIG. 59 and FIG. 60 in a viewof an order performing processes. That is, in FIG. 61 and FIG. 62, MTmessage processing steps S5501 to S5508, and S5601 to S5608, areperformed before performing MO message processing steps S5509 to S5527,and S5609 to S632. However, steps for processing an MO message, andsteps of processing an MT message in FIG. 61 and FIG. 62 are identicalto those in FIG. 59 and FIG. 60, respectively.

As described above, various MT message processing services and MOmessage processing services can be developed and supported using theopen mobile business supporting system according to an embodiment of thepresent invention. Also, as the MO-MT message processes are processedcollectively, a reasonable billing process can be performed.

FIG. 63 is a block diagram illustrating a configuration for providing areport after transmitting a message in an open mobile businesssupporting system according to an embodiment of the present invention.

Referring to FIG. 63, the open mobile business supporting systemaccording to an embodiment of the present invention includes an openinterface OI processing unit 100 connected to a client content/serviceproviding system CP/SP 11 a, and a report open interface (ROI)processing unit 111 connected to the business logic processing unit 200and a server content/service providing system CP/SP 11 b.

The client CP/SP 11 a is a system that performs a CP/SP to Phone directMT messaging service for providing an SMS or an MMS message such astexts, pictures, and multimedia files to a user's mobile terminal.

The server CP/SP 11 b is a system that wants to receive a report messagein real time as an SMS or MMS message transmission result from theclient CP/SP 11 a for a request of transmitting an SMS or MMS messagefrom the client CP/SP 11 a. In FIG. 63, the client CP/SP 11 a and theserver CP/SP 11 b are described as an independent system. However, theycan be embodied as single system according to a service type and aservice provider type. The described configuration can provide a reportin real time based on the identical integrated specification not onlyfor an SMS or MMS message but also for various other legacy systems.

The business logic processing unit 200 defines and standardizes thebusiness logic and manages it as a biz template. The business logicprocessing unit 200 transmits an SMS or an MMS message to a userterminal 14 by performing a biz template according to a result ofperforming the biz template through cooperating with an MP/MMSC 130 in alegacy system, and receives a report message as the result oftransmitting the SMS or MMS message. The report message includesinformation about the result of message transmission such as whether theSMS or MMS message is successfully transmitted or not.

The ROI processing unit 111 receives the report message from thebusiness logic processing unit 200 and provides the received reportmessage to the server CP/SP 11 b.

FIG. 64 is a block diagram illustrating a report open interface (ROI)processing unit 111 shown in FIG. 63.

Referring to FIG. 64, the ROI processing unit 11 includes an MQ adapter111-1, a message analyzer 111-2, a message builder 111-3, a reportmanager 111-4, a report sender 111-5, a Log manager 111-6, and aconfiguration manager 111-7.

The MQ adapter 111-1 transmits and receives a report message to/from thebusiness logic processing unit 200 through a message queue 816. The MQadapter 111-1 includes a BIE receiver 111-1 a and a BIE transmitter111-1 b. The BIE receiver 111-1 a receives a report message from thebusiness logic processing unit 200 through a message queue 816. The BIEtransmitter 111-1 b transmits a report message to the business logicprocessing unit 200 through message queue 816.

The message analyzer 111-2 receives the report message from the MQadaptor 111-1 and transforms the received report message to have a classstructure that can be recognized in the ROI processing unit 111.

The message builder 111-3 receives the report message from the messageanalyzer 111-2, and transforms the received report message to be usablein the server CP/SP 11 b.

The report manager 111-4 receives the report message from the messagebuilder 111-3 and relays the report message to the server CP/SP 11 b tobe transmitted.

The report sender 111-5 receives the report message from the reportmanager 111-4 and transmits the received report message to the serverCP/SP 11 b.

The Log manager 111-6 standardizes a log format per a log level ofconstitutional modules 111-1 to 111-7 of the ROI processing unit 111.That is, the log manager 111-6 creates a system log for a log level anda log form assigned from each constitutional module 111-1 to 111-7, andtransmits the created system log to OMS 700 using FTP to manage thecreated system logs. The log information can be created based ondebugging information, malfunction information, and system operatinginformation, which are generated from the constitutional modules 111-1to 111-7 of the ROI processing unit 111. Also, the log level can besetup according to a system environment. For example, various log levelscan be defined as an error level, an information providing level, awarning lever, and a debug level for leaving the lowest detail. The logis generated according to the log level defined according to theenvironment.

The configuration manager 111-7 stores and manages environment settingssuch as a system environment or a log generation period for theconstitutional modules 111-1 to 111-7 of the ROI processing unit 111 toan internal configuration file (not shown). The configuration manager111-7 can be embodied to reflect the modification of the configurationfile by re-driving the ROI processing unit 111 or to instantly reflectthe modification of the configuration file in real time withoutre-driving the ROI processing unit 111. That is, the configurationmanager 111-7 manages modifications using the internal configurationfile when the execution environment of each constitutional module of theROI processing unit 111 is changed. The configuration manager 111-7 canset up the execution environment by reading the configuration file inreal time when the system is driven. In order to manage theconfiguration information, KEY values of predetermined program orconfiguration information are received from a desired module, and aconfiguration information value is inquired. Also, configurationinformation can be inquired, modified, and deleted by directly accessthe configuration file. When the configuration information is modified,deleted, or inputted, the configuration manager 11-7 reflects theconfiguration information to the current ROI processing unit 111 in realtime in order to allow a program or a module to use the reflectedconfiguration information.

FIG. 65 is a flowchart illustrating a procedure of providing a reportthrough an open mobile business supporting system of FIG. 63 aftertransmitting a message according to an embodiment of the presentinvention.

Referring FIG. 65, when performing a CP/SP to Phone direct MT messagingservice that transmits an SMS or MMS message including a text, apicture, and a multimedia file to a user terminal 14 from the clientCP/SP 11 a using the open mobile business supporting system, the OIprocessing unit 100 requests to process a business logic that performs asingle function among logics constituting an MT message service in stepS5901. When the client CP/SP 11 a requests the business logic process inthe step S5901, it may be desirable to include a server IP address orport information of the server CP/SP 11 b in the business logicprocessing request message in order to transmit a report message for theresult of performing the biz template of the business logic to apre-assigned server CP/SP 11 b.

Then, the OI processing unit 100 request the business logic processingunit 200 to perform the biz template, and the business logic processingunit 200 performs the biz template in step S5902.

Then, the business logic processing unit 200 cooperates with the MP/MMSC39 through the MT cooperating unit 528 of the legacy cooperationprocessing unit 500, thereby transmitting an SMS or MMS message to theuser terminal 14 in step S5903.

The business logic processing unit 200 receives a report message fromthe MT cooperating unit 528, which informs whether the SMS or MMSmessage is successfully transmitted to the user terminal 14 or not, andtransmits the received report message to the server CP/SP 11 b in stepS5904, thereby providing a real time report of the MT messagetransmission according to an embodiment of the present invention.

FIG. 66 is a flowchart illustrating the detailed operation of an ROIprocessing unit 111 in a real time report procedure according to anembodiment of the present invention.

Referring to FIG. 66, the ROI processing unit 111 according to anembodiment of the present invention receives a report message from thebusiness logic processing unit 200 and transmits the received reportmessage to the server CP/SP 11 b.

At first, the MQ adapter 111-1 receives the report message from thebusiness logic processing unit 200 through the message queue 817 in stepS6001.

Then, the message analyzer 111-2 receives the report message from the MQadaptor 111-1 and transforms the received report message a classstructure to be recognized in the ROI processing unit 111 in step S6002.

The message builder 111-3 receives the report message from the messageanalyzer 111-2, and transforms the report message to be usable in theserver CP/SP 11 b in step S6003.

Then, the report manager 111-4 receives the report message from themessage builder 111-3 and relays the received report message to betransmitted to the server CP/SP 11 b. The report sensor 111-5 receivesthe report message from the report manager 111-4 and transmits thereceived report message to the server CP/SP 11 b in step S6004.

In the present embodiment, the log manager 111-6 is used to create asystem log for a log level and a log form a assigned from each ofconstitutional modules 111-1 to 111-7 of the ROI processing unit 111,and the created log information is transmitted to the OMS 700 using FTP,thereby managing the log information of the ROI process 111.

In the ROI processing unit 111, the configuration manager 111-7 is usedto store and manage the environment settings such as system environmentor the log generation period for each of the constitutional modules111-1 to 111-7 of the ROI processing unit 111, thereby managing thesystem environment and the log generation period.

FIG. 67 is a block diagram illustrating an open mobile businesssupporting system for confirming a message transmission result aftertransmitting a message.

Referring to FIG. 67, the open mobile business supporting systemaccording to an embodiment of the present invention further includes aconfirm database server 113.

The confirm DB Server 113 stores information about the report messagetransmitted from the server CP/SP 11 b, and provides the stored reportmessage when the client CP/SP 11 a request the report message. Bydriving the confirm DB server 113, it is possible to confirm whether areport message is transmitted from the client CP/SP 11 a to the serverCP/SP 11 b although the report message is lost according to the networkcondition. In one embodiment, the confirm DB server 113 stores andmanages session information such as response messages exchanged toperform the biz template in the business logic processing unit 200. Thereport message and the session information stored in the confirm DBserver 194 can be directly provided from the business logic processingunit 200, or can be provided from the business logic processing unit 200through the ROI processing unit 111′. In the present embodiment, amessage can be confirmed based on an integrated specification accordingto needs. In the present embodiment, it is possible to confirm themessage transmission result based on an integrated specification notonly for the SMS or MMS message but also for various other messages forlegacy system.

The ROI processing unit 111′ further includes a confirm DB manager 111-8and a scheduler 111-9 as well as a MQ adapter 111-1, a message analyzer111-2, a message builder 111-3, a report manager 111-4, a report sender111-5, a Log manager 111-6, and a configuration manager 111-7.

The confirm DB manager 111-8 stores and manages report messages andsession information provided from the business logic processing unit 200at the confirm DB server 113.

The report message stored in the confirm DB manager 111-8 is receivedthrough the BIE receiver 111-1 a of the MQ adaptor 111-1 when the clientCP/SP 11 a requests the report message. The report manager 111-4 obtainsthe report message from the confirm DB manager 111-8, and provides theobtained report message to the business logic processing unit 200through the MQ adaptor 111-1.

The request of the report message transmitted from the client CP/SP 11 ais performed based on a session key generated to identify each businesslogic of the client CP/SP 11 a from the OI processing unit 100. Theconfirm DB manager 111-8 stores and manages the report message withreferent to session keys of corresponding business logic. Therefore,when the client CP/SP 11 a requests a report message of a predeterminedsession key to transmit, the confirm DB manager 111-8 transmits thereport message related to the corresponding session key to the clientCP/SP 11 a.

The scheduler 111-9 manages report information stored in the confirm DBserver 1113 according to a predetermined execution period and managingperiod. For example, the scheduler 111-3 can be configured to deletestored report messages at every one day period in order to prevent amemory from being overflowed due to the unnecessary messages.

FIG. 69 is a flowchart illustrating a procedure for confirming a messagetransmission result after transmitting a message in an open mobilebusiness supporting system according to an embodiment of the presentinvention.

Referring to FIG. 69, when performing a CP/SP to Phone direct MTmessaging service that provides an SMS or MMS message including a text,a picture, and a multimedia file to a user terminal 14 from a clientCP/SP 11 a using an open mobile business supporting system according toan embodiment of the present invention, the OI processing unit 100receives a request of processing a business logic that performs a singlefunction among logics constituting the MT messaging service from theclient CP/SP 191 in step S6301. It may be desirable to include a serverIP address and port information of the server CP/SP 11 b into thebusiness logic processing request message in order to transmit a reportmessage for the result of performing the biz template to a pre-assignedserver CP/SP 11 b when the client CP/SP 11 a requests the business logicprocessing in the step S6301.

Then, the OI processing unit 100 requests the business logic processingunit 200 to perform the biz template, and the business logic processingunit 200 performs the biz template in step S6302.

Therefore, the business logic processing unit 200 transmits an SMS orMMS message to a user terminal 14 by cooperating with the MP/MMSC 39through the MT cooperating unit 1528 of the legacy cooperationprocessing unit 500 in step S6303.

The business logic processing unit 200 manages the received reportmessages by storing the received report messages into the confirm DBserver 113 directly or indirectly through the ROI processing unit 111 instep S6304.

Then, the business logic processing unit 200 receives a report messagefrom the MT cooperating unit 528, which informs the result of messagetransmission such as whether the SMS or MMS message is successfullytransmitted to the user terminal 14. Then, the business logic processingunit 200 transmits the received report message to the server CP/SP 11 bin step S6305, thereby providing a real-time report of the MT messagetransmission to the server CP/SP 11 b.

Afterward, when the client CP/SP 191 requests the report message, thebusiness logic processing unit 200 obtains the report message from theconfirm DB server 113 and provides the obtained report message to theclient CP/SP 11 a. The business logic processing unit 200 can beconfigured to directly obtain the report message from the confirm DBserver 113 or to indirectly obtain the report message through the ROIprocessing unit 111′.

FIG. 70 is a diagram illustrating the operations of an ROI processingunit 111′ according to an embodiment of the present invention.

Referring to FIG. 70, the ROI processing unit 111′ receives the reportmessage from the business logic processing unit 200 and transmits thereceived report message to the serer CP/SP 11 b as follows.

At first, the MQ adapter 111-1 receives a report message from thebusiness logic processing unit 200 through a message queue 817 a in stepS6401.

The confirm DB manager 111-8 stores the received report message in theconfirm DB server 113 and manages the stored report message in stepS6402.

The message analyzer 111-2 receives the report message from the MQadaptor 111-1 and transforms the received report message to a classstructure to be recognized in the ROI processing unit 111′ in stepS6403.

The message builder 111-3 receives the report message from the messageanalyzer 111-2 and transforms the report message to be usable in theserver CP/SP 11 b in step S6404.

The report manager 111-4 receives the report message from the messagebuilder 111-3 and relays the report message to transmit it to the serverCP/SP 11 b, and the report sender 111-5 receives the report message fromthe report manager 111-4 and transmits the received report message tothe server CP/SP 11 b in step S6405.

Then, when the business logic processing unit 200 requests the reportmessage stored in the confirm DB server 113, the report manger 111-4determines whether the business logic processing unit 200 request thereport message or not in step S6306. In case of the report messagerequest, the report manager 111-4 transmits a report message, which isstored in the confirm DB server 113 and have relation to a uniquesession key of a corresponding request, to the business logic processingunit 200 in step S6407.

The scheduler 111-9 determines whether a period for storing the repotmessage in the confirm DB server 113 based on a predetermined executionperiod and managing period is expired or not in step S6408. In case ofexpiration, the report message with the storing period expired isremoved from the confirm DB server 113, thereby preventing the confirmDB server 113 from being overflowed.

Although some embodiments of the present invention have been disclosedfor illustrative purpose, those skilled in the art will appreciate thatvarious modifications, additions and/or substitutions can be madewithout departing from the scope and spirit of the invention as definedin the accompanying claims.

According to certain embodiments of the present invention, the openmobile business supporting system supports various infra resources in awireless communication system to be independently operated andintegrally driven, thereby allowing various infra resources to beconveniently and effectively cooperated with one another. Furthermore,the open mobile business supporting system provides an integratedinterface for the infra resources in the wireless communication system.Therefore, a service and an application layer can easily use the infraresources of the wireless communication system.

Moreover, the open mobile business supporting system according tocertain embodiments of the present invention classifies biz logicmanagement, service management, and service execution, therebyeffectively supporting various business models.

1-25. (canceled)
 26. A billing device for a mobile communication systemto be cooperated in an open mobile business supporting system, thebilling device comprising hardware that defines: a business logicprocessor configured to store, manage, and perform a biz template formedof at least one biz object arranged according to a flow of acorresponding biz logic, wherein the biz template is a standardized bizlogic that is defined by selecting low-level functions which can begrouped as a unit function and performed in the mobile communicationsystem among service logics provided from a content provider/serviceprovider (CP/SP), wherein the at least one biz object includes at leastone of a first biz object associated with a first function requiring tocooperate with a corresponding legacy system of the mobile communicationsystem and a second biz object associated with a second functionperforming a comparison and determination operation based on the resultof cooperating, and wherein the standardized biz logic is defined basedon frequency of use and reusability of corresponding functions by atleast one CP/SP; an open interface processor configured to receive arequest of performing a predetermined biz logic from the CP/SP through anetwork, request the business logic processor to perform a biz templatecorresponding to the requested biz logic, receive the result of therequest, and transfer the received result to the CP/SP through thenetwork; a legacy cooperation processor configured to relay a requestfrom a predetermined legacy system and return the result to thepredetermined legacy system while performing a biz template by relayinginterworking between the business logic processor and a legacy system ofthe mobile communication system; an infra channel provider configured toreceive a request of performing a biz object from a legacy system of themobile communication system, perform the biz object by cooperating withanother legacy system through the legacy cooperation processor, andtransfer the result to a corresponding legacy system; and a billingprocessor configured to collect billing logs generated by performing abiz template at the business logic processor or by performing a bizobject in the infra channel provider, process the collected billinglogs, and transfer the processed billing log to the billing legacysystem, wherein the billing processor cooperates with the business logicprocessor through a message queue.
 27. The billing device according toclaim 26, wherein the billing processor comprises: a billing log parserconfigured to collect billing logs generated by performing a biztemplate at the business logic processor, check a validity of thecollected billing logs, and standardize the valid billing logs; abilling policy DB configured to store a plurality of billing policiesand billing data; a billing policy processor configured to inquire abilling policy to be applied to the standardized billing log from thebilling database; a billing file generator configured to generate abilling file (MDR) for transmitting to the legacy system of the mobilecommunication system using the billing data; and a billing datatransmitter configured to transmit the generated billing file (MDR) tothe billing legacy system.
 28. The billing device according to claim 27,wherein the billing policy processor further comprises an authenticationprocessor configured to perform a user authentication operation.
 29. Thebilling device according to claim 27, wherein the billing policyprocessor comprises: a log receiver configured to receive a billing logstandardized and process from the billing log parser, a log transferringprocessor configured to filter overlapped billing logs in the collectedbilling logs and transmit the filtered billing logs to a billingprocessing table; and a billing sub-processor configured to perform abilling process by applying a predetermined billing policy according toa billing log transferred from the billing process table, and generatebilling data.
 30. The billing device according to claim 27, wherein thebilling processor further comprises a prepay and pre-subtracting billingprocessor configured to request a pre-payment pre-subtraction billinglegacy system to perform a prepay and pre-subtracting billing process,which receives a prepay and pre-subtracting billing request from thebusiness logic processor, receive the result thereof, and transfer thereceived result.
 31. The billing device according to claim 30, whereinthe billing log parser is configured to verify a validity of apredetermined billing log with the prepay and pre-subtracting billingprocess requested, and standardize the billing log transferred from theprepay and pre-subtracting billing processor.
 32. The billing deviceaccording to claim 27, wherein the billing processor further comprises apolicy manager configured to register, modify, and delete at least oneof billing policies selected from billing information synchronization ofbiz template and content, event management, billing verification,billing policy synchronization, and a billing policy backup from therepository DB when the billing policy is requested, and respond to therequest.
 33. The billing device according to claim 27, wherein thebilling processor further comprises a load manager configured to managecommon log formats of the billing processor, creation and record of asystem log, processing completed log files.
 34. The billing deviceaccording to claim 27, wherein the billing processor further comprises aDB manager configured to access the database from the billing processor,manage the access thereof, and release the accesses by cooperating witha predetermined database.
 35. The billing device according to claim 27,wherein the billing processor further comprises a configuration managerconfigured to inquire and manage a setup file and a unique setup filecommonly used in a system.
 36. The billing device according to claim 27,wherein the billing processor further comprises an operating andmanagement system (OMS) manager for collecting, transmitting, andmanaging operating and managing (O&M) of the billing processor managedfrom the OMS manager by cooperating with a predetermined O&M system. 37.A billing processing method for processing a billing based on performinga biz template, in a billing processing device comprising: collecting,by a billing log parser including a hardware processor, a billing loggenerated according to performing a biz template formed of at least onebiz object at a business logic processing module, wherein the biztemplate is a standardized biz logic that is defined by selectinglow-level functions which can be grouped as a unit function andperformed in a mobile communication system among service logics providedfrom a content provider/service provider (CP/SP); wherein the at leastone biz object includes at least one of a first biz object associatedwith a first function requiring to cooperate with a corresponding legacysystem of the mobile communication system and a second biz objectassociated with a second function performing a comparison anddetermination operation based on the result of cooperating; wherein thestandardized biz logic is defined based on frequency of use andreusability of corresponding functions by at least one CP/SP; andwherein a billing processing module cooperates with the business logicprocessing module through a message queue to collect the billing log;verifying, by the billing log parser, validity of the collected billinglog; performing, by the billing log parser, a standardizing process onthe verified billing log; generating, by a billing policy module,billing data by applying a predetermined billing policy according to thestandardized billing log; generating, by a billing file generator, abilling file (MDR) to transmit to a billing legacy system of the mobilecommunication system using the generated billing data; and transmitting,by a billing data transmitter, the generated billing file (MDR) to thebilling legacy system.
 38. The billing processing method according toclaim 37, wherein the collecting further comprises collecting a billinglog for content or a user provided from the CP/SP.
 39. The billingprocessing method according to claim 37, wherein, in the verifying, thecollected billing logs are classified by a type, and the validitythereof is verified.
 40. The billing processing method according toclaim 37, wherein the generating further comprises performing a userauthentication process corresponding to a billing log.
 41. The billingprocessing method according to claim 37, wherein the generating billingdata comprises: inquiring a billing policy to be applied to thestandardized billing log from a predetermined billing policy database;generating billing data by applying the inquired billing policy to thebilling log; and generating a billing file (MDR) based on the generatedbilling data.
 42. The billing processing method according to claim 37,wherein, in the generating, the billing file (MDR) is generated to besuitable for a file transport protocol (FTP) based on the billingprocessed billing data.
 43. The billing processing method according toclaim 37, wherein, in the transmitting, the generated billing file istransmitted to the billing legacy system using FTP.
 44. The billingprocessing method according to claim 37, wherein the verifyingcomprises: receiving a request of performing a prepay andpre-subtracting billing process for a billing log received from thebusiness logic processing module; requesting a predetermined prepay andpre-subtracting billing process, which performs a prepay andpre-subtracting billing process in response to the request, to performthe prepay and pre-subtracting billing process; and receiving a responseto the request.
 45. A billing device for processing a billing based onperforming a biz template comprising: a parsing module, including ahardware processor, configured to: (a) collect a billing log accordingto the performing the biz template formed of at least one biz object ata business logic processing module, wherein the biz template is astandardized biz logic that is defined by selecting low-level functionswhich can be grouped as a unit function and performed in a mobilecommunication system among service logics provided from a contentprovider/service provider (CP/SP); wherein the at least one biz objectincludes at least one of a first biz object associated with a firstfunction requiring to cooperate with a corresponding legacy system ofthe mobile communication system and a second biz object associated witha second function performing a comparison and determination operationbased on the result of cooperating; wherein the standardized biz logicis defined based on frequency of use and reusability of correspondingfunctions by at least one CP/SP; and wherein a billing processing modulecooperates with the business logic processing module through a messagequeue to collect the billing log; (b) verify validity of the collectedbilling log; and (c) perform a standardizing process on the verifiedbilling log; a billing policy module configured to generate billing databy applying a predetermined billing policy according to the standardizedbilling log; a generating module to configured to generate a billingfile (MDR) to transmit to a billing legacy system of a mobilecommunication system using the generated billing data; and atransmitting module configured to transmit the generated billing file(MDR) to the billing legacy system.